4 ms·

XML and JSON are different data formats with different properties and different uses. Please, don't blame one and praise the other, just use what's appropriate

XML and JSON are different data formats with different properties and different uses. Please, don't blame one and praise the other, just use what's appropriate. It's somehow like with data structures - say, one won't generally use a graph when he actually needs a set, right? Trying to stash data into a semantically inappropriate format leads to kludges, and I'd say some JSON-based formats (for example, HAL-JSON) feel like so. Obviously, it's the same (or, possibly, even worse) for XMLish abominations like SOAP. Neither XML nor JSON are silver bullets. My point is, while sure, XML has its issues and arcane features, it's not universally terrible. Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible yet still functional and expressive subset of XML for the most typical use cases, huh. Somehow in a same manner, XML was "extracted" from SGML.

sk5t 12y ago
Why the nasty words for SOAP/XML? I mean, it can be kind of unpleasant to work with, but it holds some major advantages over popular alternatives for building and consuming non-trivial web APIs. WSDL as a mechanism to describe serialization style, operations, endpoints, data types and enums, security bindings, etc., plus all the tooling it makes possible are quite powerful.
- NelsonMinar 12y ago
  Wow, are some poor bastards still using WSDL somewhere? I thought it was long dead. Back in 2006 I wrote up a quick bit on why SOAP sucks, my experience of running a couple of Google public SOAP services. Basically none of the stuff you describe actually works. http://www.somebits.com/weblog/tech/bad/whySoapSucks.html http://www.somebits.com/weblog/tech/bad/whySoapSucks.html
  - sk5t 12y ago
    SOAP/XML, WSDL, and related tooling are not always a walk in the park, but they certainly haven't faded into history. Indeed there are plenty of pathological cases, and overblown, tool-bound APIs designed by architecture astronauts, but it is also possible to publish and consume them in a manner just as simple and straightforward as the examples suggest. Taking just one example from my own experience, Salesforce's SOAP/XML services have proven easy to use, sensibly managed and versioned, and far quicker than hand-building structures to manage "simpler" REST.
toyg 12y ago
> Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible If you ignore Schema (and all the WS-* stuff that requires them), the rest is as simple as it comes, even if you include DTDs. Which is why XML is used in a number of roles and people at one point thought it was the best invention since sliced bread.
jbergens 12y ago
The problem discussed are that XML is somewhat complicated to parse correctly. If you only support a subset of XML then it is easy to parse. The problem is that I might not know what subset you are using. When I send you advanced XML (since you said you support XML) something might crash. There is probably a need for a simpler subset of XML with its own name (like XML 2.0 or XML-WS or Mini-XML). Personally I would like to skip the requirement for a root element. Since json is a bit simpler it has less of these problems. Of course it has other problems but that is another thing.

sk5t 12y ago

Why the nasty words for SOAP/XML? I mean, it can be kind of unpleasant to work with, but it holds some major advantages over popular alternatives for building and consuming non-trivial web APIs. WSDL as a mechanism to describe serialization style, operations, endpoints, data types and enums, security bindings, etc., plus all the tooling it makes possible are quite powerful.

NelsonMinar 12y ago
Wow, are some poor bastards still using WSDL somewhere? I thought it was long dead. Back in 2006 I wrote up a quick bit on why SOAP sucks, my experience of running a couple of Google public SOAP services. Basically none of the stuff you describe actually works. http://www.somebits.com/weblog/tech/bad/whySoapSucks.html http://www.somebits.com/weblog/tech/bad/whySoapSucks.html
- sk5t 12y ago
  SOAP/XML, WSDL, and related tooling are not always a walk in the park, but they certainly haven't faded into history. Indeed there are plenty of pathological cases, and overblown, tool-bound APIs designed by architecture astronauts, but it is also possible to publish and consume them in a manner just as simple and straightforward as the examples suggest. Taking just one example from my own experience, Salesforce's SOAP/XML services have proven easy to use, sensibly managed and versioned, and far quicker than hand-building structures to manage "simpler" REST.

toyg 12y ago

> Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible If you ignore Schema (and all the WS-* stuff that requires them), the rest is as simple as it comes, even if you include DTDs. Which is why XML is used in a number of roles and people at one point thought it was the best invention since sliced bread.

jbergens 12y ago

The problem discussed are that XML is somewhat complicated to parse correctly. If you only support a subset of XML then it is easy to parse. The problem is that I might not know what subset you are using. When I send you advanced XML (since you said you support XML) something might crash. There is probably a need for a simpler subset of XML with its own name (like XML 2.0 or XML-WS or Mini-XML). Personally I would like to skip the requirement for a root element. Since json is a bit simpler it has less of these problems. Of course it has other problems but that is another thing.