I don't love XML or hate JSON, but part of my job involves writing Flash/AVM1 (ActionScript 2) code that runs on slow CPUs (yes, feel free to pity me).
I can get reasonable performance out of large XML results because the XML is parsed inside the Flash VM by native code. There is no such luxury for JSON, so I have to resort to writing hacky non-compliant "JSON parsers" in ActionScript that are optimized for specific data sets (because the slow-CPU/Flash-AVM1 combo means a true compliant JSON parser for the full API result is just way too slow).
So, while I may much rather be using JSON (or better yet, protobufs of thrift) for everything in a totally different environment, I do appreciate APIs giving me XML results because of my specialized situation.
It's embarrassing that most live JSON-based protocols, including my employer's, hearken back to the painful garbage-in garbage-out dawn of the industry (what with ad hoc validation and no schema at all). It's hard to overstate the importance of every implementation agreeing on whether or not a given message should work. That's the only knock against JSON I know of, apart from bloat of course (but XML is worse).
But there isn't much to learn while parsing JSON. It nicely maps to high level languages. It does make your knowledge of XML useless, but it doesn't has the cognitive overhead of learning something which takes time and effort.
You've got to know when each is suitable. Doing REST properly in JSON involves hacks and trade-offs that you don't have to make with XML. The classic example is how you encode a link with a relationship - XML is rich enough to make it trivial. With JSON, you either have to specify a microformat, or rely on mutually agreed regex-matching rules on raw strings (which sucks, but might be enough in a restricted scenario).
Then you've got namespaces, entities and validation - all things which might cause someone to say "I'm inevitably going to need X in all my applications, therefore JSON can never be suitable." They'd probably be overgeneralising, but I can certainly see how it would lead to a preference for XML over JSON.
right, i can't think of anyone that prefers xml over json-- xml seems too bloated, dom and sax parsers require lots of code to walk trees compared to just a single json parse call and then you can just directly access things in an object. though i have had to write several json decoder/encoders for special objects.
for my internal rest apis, the only response format i provide is json, this is for mvp purposes. though i will add xml when i publicize these apis.
My understanding is that REST imposes a bunch of restrictions about how an API is suppose to work.
For example the idea that you can just communicate a single base URL and document formats, and other urls are deduced from that. Which add complexity, but make the system more able to evolve.
My thinking is that these constraints are inappropriate for an internal API, where you could embed knowledge of how to construct a number of URL's in clients.
Also some tools, like .NET, have good support for mapping XML schema's to classes, and I don't know of equivalents for JSON.
To cite Wikipedia¹, “The XML encoding may therefore be shorter than the equivalent JSON encoding.” Please provide a fragment of XML document that is significantly more verbose than its JSON counterpart.
> dom and sax parsers require lots of code to walk trees compared to just a single json parse call and then you can just directly access things in an object.
Using DOM/SAX (especially SAX) is like walking the JSON's AST. You're doing it wrong (this is too low-level).
The second problem with this argument, is that people using it are selling you something that isn't real. You can't just ‘directly access things in object.’ You need to deal with untrusted input that is just coincidentally mapped to your very basic data structures (dictionaries, lists and numbers and strings). You will have to write schema—it will most likely be something that is different to each ecosystem (Y.Dataschema.JSON for Javascript, Colander for Python, etc.), and then you will consume exactly what you would consume with any other format, be it XML or Thrift or PB, that is your DAL objects, your representation objects if you're doing REST.
If you are doing it any other way, if you're doing it the naïve way, you're living in a fantasy land—you're using not only something that wouldn't scale, but something that is unsafe and unnecessary, yes!, verbose.
A very simple case for a web-application (and this is for where I argue), is that by using JSON.load() you're loading everything to memory. That makes you vulnerable for a simple dumb attack like this:
So you need to use streaming parser with a schema, to drop request when there's first sign of trouble, or you need to limit your webapps to requests that are no more than thiiis big, which of course limits you as to what you can include in that JSON document (if you want to include 5MB file, you will need to be ready for 5MB of nested dictionaries and lists). Not that you can't do that with JSON, however it's not just JSON.loads() anymore, now is it?
You asked why someone would prefer XML over JSON. Well apart from XML having dealt with all of this issues long time ago and is widely supported, how about the fact that XML is great for the Open Web and JSON will slowly kill it?²
It's not a matter of love/hate, but I've found it's a lot easier to sell something as "a web service using XML" than "a RESTful API using JSON". People know what XML is, not everyone has heard of JSON.
Does anyone love XML and hate JSON?