The JSON vs XML debate begins in earnest

 

After seeing  Douglas Crockford's talk on JSON at XML 2006 recently, I figured that some sort of great debate between XML and JSON advocates was brewing.  I had been waiting for Elliotte Harold's rebuttal of what Crockford is missing, but haven't seen it yet.  What has happened is that Dave Winer got off a  rant against JSON as reinventing XML's (and more specifically XML-RPC's) wheel:

God bless the re-inventers

Gotta love em, because there's no way they're going to stop breaking what works, and fixing what don't need no fixing

Crockford gets off a very pithy response: 

The good thing about reinventing the wheel is that you can get a round one.

There are a lot of other very interesting observations in that comment thread.  Some points that hadn't been obvious before to me include:

  • There seemed to be a lot more JSON fans than XML fans in that thread (maybe because the original post was just a wee bit inflammatory)
  • JSON may be something like 100x faster to parse than XML in today's browsers (but I doubt very much if the best JSON parsers are anywhere near that much faster than the best XML parsers ... it would be interesting to know!),
  • JSON parsing ends up with something akin to a  typed "business object" rather than an untyped DOM tree
  • To do that in XML requires yet another layer or two of cruft (a schema and a databinding tool)
  • The bottom line argument for JSON comes down to elegance -- it does what is does simply and cleanly, and simply refuses to worry about many of the things that complicate XML such as metadata (attributes), comments, processing instructions, a schema language, and namespaces.

As a 10 year XML veteran, and informal minister of propaganda for the "XML Team", aren't I supposed to leap to XML's defense?  I just can't summon the energy.  First, XML's lack of elegance, presumably the result of its genesis in a series of committee rooms and compromises, is unarguable. One just can't look at it without remembering the old saw that a "camel is a horse designed by a committee." I'm not sure if that's a problem, since I like the comeback "but a camel is a lot more sturdy beast if you are exploring the unknown."  Still, horses' elegance generates a lot more enthusiasm in the rest of the world than camels' sturdy pragmatism does.

Second, it's also hard to argue with the proposition that the XML wheel could be a lot rounder.  As far as I can tell, there is just about zero enthusiasm among XML cognoscenti for re-opening the debates from a decade ago about which aspects of XML (or SGML) are "features" and which are "bugs" -- it depends on who is doing what, and whether there are enough people doing it to matter.  By making evolution toward something more simple and secure impossible, the XML community made something like the JSON revolution inevitable.  That doesn't mean that the revolutionaries will win;  after all, JSON's own limitations will become apparent only once is tested in scenarios that were not anticipated by its designers . At a minimum, a few key victories for the revolutionaries might motivate the old guard to make some needed reforms.

Third, the fact that the argument for JSON comes down to a matter of elegance doesn't bode well for its ultimate success.  It's hard to forget the famous lament of a LISP devotee reflecting on its lack of success against the much less elegant C/Unix/etc. competition: Worse is Better. I wonder how many of the legitimate challenges that people are finding easier to solve with JSON than XML (especially the infamous cross-domain data mashup problem imposed by XmlHttpRequest's security model) mightn't be solved more expediently with some small tweaks to the XML infrastructure rather than a wholesale adoption of a disruptive innovation such as JSON. 

Finally, in the larger scheme of things it doesn't matter.  What does matter is that there be standardized, widely supported means for making data interoperable across applications, platforms, programming languages, and time.  Life would be easier for us infrastructure implementers if there were a single, stable standard, but it's unrealistic to expect that XML 1.0 would be the last word on the subject.  We will cope with whatever happens -- small tweaks to address critical bugs that JSON illuminates, multiple de facto data interoperability standards,  guided evolution of XML to be a better universal data interchange format, or wholesale revolution to produce a better world.

 

It would be nice if the JSON vs XML debate does not go the way of the "REST vs Web Services" perma-talking-past-one-another-fest.  Ultimately they are very likely to end up in the same place.  As Eric Newcomer puts it:

once a technology passes the hype cycle and becomes adopted, all its warts and bumps become more obvious as we find out what it is really good for, and what it is not...we should no more propose Web services as the right solution for everything than we should propose REST as the right solution for everything.

I hope nobody proposes JSON as the right solution for everything, and that the debate reminds us that XML is not the right solution for everything. One way or another, this debate will take us toward either a couple of rounder wheels better fit for their specialized purposes, or inspire a next-generation wheel that really does better than either do well today.

 

 

 Quick update with some other interesting links: (Winer's piece made the top of Techmeme while I was typing ...)

Dare Obasanjo

The obvious reaction was to make the Google and del.icio.us announcements into a REST vs. SOAP or XML vs. JSON story since geeks like to turn every business decision into a technology decision. However if you scratch the surface, the one thing that is slowly becoming clear is that providers of data services would rather provide you their data in ways they can explicitly monetize (e.g. driving traffic to their social bookmarking site or showing their search ads) instead of letting you drain their resources for free no matter how much geek cred it gets them in the blogosphere.

Simon Willison

The sweet spot for JSON is serializing simple data structures for transfer between programming languages. If you need more complex data structures (maybe with some kind of schema for validation), use XML. If you want to do full blown RPC use SOAP or XML-RPC. If you just want a light-weight format for moving data around, JSON fits the bill admirably.

What do we lose from not using XML? The ability to use XML tools. If you’re someone who breathes XSLT that might be a problem; if like me your approach when faced with XML is to parse it in to a more agreeable data structure as soon as possible you’ll find JSON far more productive.