4 ms·

The second section discusses SOAP/REST and XML/JSON, saying that XML Schema attempted to solve two problems (document formats + object wire format), but it pred

by 10ren 16y ago

The second section discusses SOAP/REST and XML/JSON, saying that XML Schema attempted to solve two problems (document formats + object wire format), but it predictably became too complex. He claims that we now use REST (not SOAP) and JSON (not XML), so the "impedance mismatch" problem is now solved. Is this true? JSON is used mainly where there is Javascript (ie. client side webpages - though that is becoming more and more inclusive these days... almost everything is a webapp (exceptions?)) - but it's schemaless (or typeless). While this is popular (eg key-value NoSQL stores, and dynamic typing in Ruby, Python, Perl), it's not right for everything. If you did want typed data, you'd probably just use XML Schema, since everything is already there. I ask because of a startup idea based on XML Schema. It could survive XML Schema going away, but I'm not so sure about the apparent long-term trend away from schemas/types altogether. With fast-enough computers to nullify the speed advantage of static types, will the remaining advantage of type-safety be valuable enough on its own - What is the evidence for and against? Even databases are going schemaless (it seems).

arebop 16y ago
If I wanted typed data, I would be more inclined to use RelaxNG than XML Schema. In some situations, XML might not be so advantageous. JSON is quite convenient for JavaScript applications. Protocol Buffers have an efficient wire representation. I think his point of JSON vs. XML is that JSON is simpler because it is designed specifically for representing structured data exchanged among JavaScript programs. Sure, it can be used from other languages and read by humans, but the design goal was much more narrowly circumscribed than the design goals of SGML, XML, and XML-Schema. The argument about SOAP vs. REST is not as well-developed, but I think he's saying that SOAP was doomed by its attempt to stretch XML to serve one too many masters. Personally though I see REST as a set of principles more than an RPC standard. It seems to me that REST's success is due both to the evolutionary manner in which it developed, and the relatively simple architectural form it takes compared to the SOAP/WS-* protocol specifications.

by 10ren 16y ago

arebop 16y ago

If I wanted typed data, I would be more inclined to use RelaxNG than XML Schema. In some situations, XML might not be so advantageous. JSON is quite convenient for JavaScript applications. Protocol Buffers have an efficient wire representation. I think his point of JSON vs. XML is that JSON is simpler because it is designed specifically for representing structured data exchanged among JavaScript programs. Sure, it can be used from other languages and read by humans, but the design goal was much more narrowly circumscribed than the design goals of SGML, XML, and XML-Schema. The argument about SOAP vs. REST is not as well-developed, but I think he's saying that SOAP was doomed by its attempt to stretch XML to serve one too many masters. Personally though I see REST as a set of principles more than an RPC standard. It seems to me that REST's success is due both to the evolutionary manner in which it developed, and the relatively simple architectural form it takes compared to the SOAP/WS-* protocol specifications.