JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
A generic XML DOM is still complicated to deal with. Even if you do the "right thing" and use XPath, you still have to deal with XPath because you can't get around the fact that you have an underlying representation that has at least two dimensions (attributes vs. CDATA). That is, just as the article says, you have more degrees of freedom in how you represent your data, and what is a "degree of freedom" but a near synonym of "dimensionality"? You can't abstract around dimensionality very effectively without losing fundamental capabilities in the underlying component (in fact a staggering number of abstraction failures in general can be shown to come from exactly this problem if you really learn to think this way), and the complexity comes poking out in the XPath. It's still better than groveling over the DOM yourself, but it's probably also the absolute peak of concision that is obtainable; there will be nothing better.
JSON is indeed simpler in that you don't really have 3 or 4 feasible choices per attribute; {"first-name": "John", "last-name": "Smith"} is pretty much your choice, full stop. That leaves the underlying library fundamentally, not accidentally, simpler. This can get you into some trouble in some cases, for instance XML is a better choice for HTML-type tagged text as the JSON for tagged-text is just hideous (and, interestingly, reopens the dimensionality problem as there is no one obvious solution), but many things are fundamentally simpler than tagged-text.
If you want to pick up a defined serialization format, my gut would be to say to default to JSON and back to XML if you really need it for something... but be aware that you may, and it's no better to try to jam JSON on top of a fundamentally XML problem. (Besides, your JSON can carry bits of XML in it without much pain, so "best of both worlds" is perfectly feasible.)
(Although I like it when my target web apps use XML; better tools support for attacking them.)
With json I have to resort to imperative means and care about the middle layers. That means refactorings are more likely to break software.
Fundamentally there is no reason why json cannot have it's own selector which traverses the tree. There just isn't one that I know of though.
I've gotten the informal impression that incidental complexity (you know, complexity arising not from the problem but the solution) is a factor behind the hugeness of the XML ecosystem, but I'd be happy to learn otherwise...
You are absolutely correct.
As Phil Wadler put it: "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."
It makes a trivial issue into a byzantine enterprise.
But, it has created a whole industry of 'experts', standard committees and other busybodies, so it must be good for the economy at least!
The CPU is spending more time dealing with XML than it is doing useful work. If it's a big file, this is very significant.
In JSON, you get the same expressiveness without the hassle.
An XML parser has to track open tag names, with JSON it doesn't matter. XML has all stupid entities like & which look ugly and need to be parsed.
I think "time to write a parser" should be a good metric on how sane a data format is. The fact that writing an XML parser that covers all bases/eventualities is a major undertaking says alot about the data format.
However, that statement should be understood through the filter of the fact that I've only seen one thing that uses XML namespaces properly, and that's XHTML. Everything else I've seen gets it wrong, and that includes most things trying to deal with XHTML....
You also get a "free" and modestly powerful validation system, a serialization format that has seriously thought through encoding issues and has answer for them (JSON does too, but a lot of other fly-by-night stuff doesn't), a fairly powerful format for tagged text (JSON-tagged text is a hack no matter how you slice it). You also get XSL, which floats some people's boats, though I wouldn't be caught dead working in it.
If you don't need any of that, don't use it. I don't very often. But when you need it, do. Also:
"An XML parser has to track open tag names, with JSON it doesn't matter."
This is equivalent to JSON needing to track {, [, ', and ", among other things. That's just parsing; both JSON and XML need to be parsed. That's not an advantage.
"XML has all stupid entities like & which look ugly and need to be parsed."
This is equivalent to the escape sequences in JSON: http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that.
JSON can simply count brackets. That makes for a very simple parser indeed. XML needs to cope with invalid nesting, end tag names not matching start tag names etc. End tag names are just wasted space.
>> This is equivalent to the escape sequences in JSON: http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that.
But those are sane. We all escape double quotes and backslashes in pretty much every programming language. They make sense in a very simple encoding.
Why should I need to replace & with %amp; they seem arbitrary, and the replacements aren't simple. " ?? seriously? you're naming characters with odd abreviations, and then expecting people to remember those? why not just escape them with a prefix such as erm.... "\"
I think you read a different spec ;) http://www.w3.org/TR/REC-xml/#sec-logical-struct :
Well-formedness constraint: Element Type Match
The Name in an element's end-tag MUST match the element type in the start-tag.
Changing " into " allows you to go to the next " without worrying about the contents before. The next " is the ending quote. Then you can resolve all the internals lazily... saving on processing time compared to JSON. For example "\"\\\"" will go through many branches and conditions. ""\"" is a simple jump over to the next " character.
In both cases --- and let's take the C implementation case --- you're still building a poorly specified buggy implementation of Tcl to actually hold the data and answer questions about it.
That's the point I'm trying to make.
Anyways, if they're equivalent, and JSON is both easier to parse and has a far higher data density.. why would anyone ever use XML for anything?
I ask myself that every day.
XML is a huge scam perpetrated on the software industry, but now it is too late because a huge parasitic 'industry' has built around it, and too many people (specially too many PHBs) have invested their reputations on XML being the ultimate standard for representing data.
<thingies> <thingy> <name>thingy1</name> </thingy> <thingy> ... </thingies>
I've seen that a billion times, if you're doing DOM, you have to pull that whole thing into memory and then run over it again. Most JSON-based storage systems I've seen recently are more record based so you can stream it through.
So I guess my beef on that one isn't specifically with XML, you could split the above snippet into separate entities.. but I'll note that it still involves about 90% markup and 10% data. Not exactly the most efficient thing possible.
You do that with JSON too, don't you? Are there SAX-like parsers for JSON?
If it's a big file it'll be big in JSON too.