I hear people saying “JSON is great, XML is over”, but I don’t hear XML partisans saying anything bad about JSON. There are two arguments that are over, though.
It seems to me that the great thing about JSON is that it exists for one purpose: to put structs on the wire. With XML, on the other hand, it’s assumed that you might want to stream it in by the gigabyte, or load it into one of a many different in-memory data structures, or run a full-text indexer over the contents, or render it for human consumption, or, well, anything.
Given JSON’s single-purpose design, generating and parsing it ought to be faster than with XML; but on the other hand, there aren’t that many apps where parsing and unparsing are a significant part of the workload.
XML’s internationalization is more thorough; it requires you to think about how you’re encoding the characters, and lets you use ISO-8859 or JIS or whatever if that’s your world. Also, while it’s not in the spec, every XML parser I’ve seen says “I’ll figure out the encoding in the incoming doc, and take care of it, and all you’ll ever see is UTF-X”, where “X” is 16 for Java and C#, 8 for almost everything else. I look at the Ruby JSON library, for example, and I see all these character encoding conversion routines; blecch.
Use JSON · Seems easy to me; if you want to serialize a data structure that’s not too text-heavy and all you want is for the receiver to get the same data structure with minimal effort, and you trust the other end to get the i18n right, JSON is hunky-dory.
Use XML · If you want to provide general-purpose data that the receiver might want to do unforeseen weird and crazy things with, or if you want to be really paranoid and picky about i18n, or if what you’re sending is more like a document than a struct, or if the order of the data matters, or if the data is potentially long-lived (as in, more than seconds) XML is the way to go.
It also seems to me that the combination of XML and XPath hits a sweet spot for data formats that need to be extensible; that is to say, it’s pretty easy to write XML-processing code that won’t fail in the presence of changes to the message format that don’t touch the piece you care about.
The Arguments Are Over · There used to be an argument about whether platform-neutral, language-neutral data formats were important, or whether distributed objects were the right answer. That’s over: HTML, XML, JSON.
There used to be people who argued that network interchange formats shouldn’t be text-based, but use binary where possible, for efficiency. That’s over: HTML, XML, JSON.
Contributions
Comment feed for ongoing:
From: Anders Pearson (Dec 21 2006, at 13:17)
"but I don’t hear XML partisans saying anything bad about JSON"
Then you missed the latest from Dave Winer where he suggests lynching the designers of JSON: http://www.scripting.com/2006/12/20.html#godBlessTheReinventers
[link]
From: Henri Sivonen (Dec 21 2006, at 13:20)
Well, there is something bad to be said about JSON: the libraries available from json.org are neither Open Source nor Free Software. Instead, they have their own non-Open Source, non-Free Software vanity license (http://www.json.org/license.html). I’d have a more favorable view of JSON if they used the MIT license (http://opensource.org/licenses/mit-license.php) verbatim.
[link]
From: John Cowan (Dec 21 2006, at 13:48)
"There used to be people who argued that network interchange formats shouldn’t be text-based, but use binary where possible, for efficiency. That’s over: HTML, XML, JSON."
Oh really? Stopped using X Windows in favor of XUL or Avalon, have we?
[link]
From: Tim Bray (Dec 21 2006, at 15:14)
Yep, John, I've disliked X windows for over a decade (and I once shipped a successful commercial Motif app, so I have standing). One of the problems with X is that the protocol was poorly documented & thus defined by the implementation.
Way back in June of 2002 (http://www.tbray.org/ongoing/When/200x/2002/06/21/GettingStarted) I wrote "It has a well-thought-through, consistent, and rather beautiful user interface that requires neither sending money to Redmond nor editing Xt resource files nor knowing what a "termcap" is."
[link]
From: Benja Fallenstein (Dec 21 2006, at 15:33)
But Tim, your argument was that HTML, XML and JSON are widely used and binary protocols are not. John pointed out that X Windows is widely used (among its target audience); I think that's a good point, whether you hate it or the protocol or not. Certainly I don't know any widely used textual protocol that fills the niche that X Windows does.
[link]
From: Name (Dec 21 2006, at 15:38)
Henri, not all of the libraries on json.org use the JSON license. In fact, there tends to be a "best of breed" in each category that is placed under a sane license. For example, I use json for communication between an app that uses Python and Java. <a href="http://cheeseshop.python.org/pypi/python-json">python-json</a> and <a href="http://developer.berlios.de/projects/jsontools/">JSON Tools</a> are both under the LGPL.
[link]
From: Aristotle Pagaltzis (Dec 21 2006, at 18:52)
Anders:
It’s a stretch to call the man who designed both RSS 2.0 and OPML an “XML partisan.”
[link]
From: John Cowan (Dec 21 2006, at 20:47)
Benja, I was making that point, but also a different point. The NeWS system <http://en.wikipedia.org/wiki/NeWS> was a competitor to X in the old days, and it did use a textual protocol for talking with graphical screens, a variant of PostScript.
NeWS failed and X succeeded -- not because the NeWS protocol was inferior, but because Sun wouldn't let anyone implement NeWS commercially without paying a stiff license fee. X had no such limitation, and the rest is history.
[link]
From: Derek (Dec 22 2006, at 06:28)
Or you could just use ASN.1, since it's significantly more efficient than XML, and the toolkits are mature, stable and relatively bug-free.
[link]
From: Joe (Dec 22 2006, at 10:24)
"There used to be people who argued that network interchange formats shouldn’t be text-based, but use binary where possible, for efficiency. That’s over: HTML, XML, JSON..."
Unless, of course, you're dealing with large amounts of data. Please, no XML based streaming video!
[link]
From: Joe Gregorio (Dec 22 2006, at 22:00)
"and you trust the other end to get the i18n right"
In my opinion JSON has a slightly better i18n story
than XML. It is always Unicode and can only
be serialized in UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE).
http://www.ietf.org/rfc/rfc4627.txt
Besides that, agreed on all points. If you don't have control of both ends of the wire then loosely typed documents beat strongly typed data-structure serializations.
[link]
From: Anton McConville (Dec 23 2006, at 06:57)
JSON is a natural fit for Dojo and YUI, and other 'Ajax' toolkits. It is a really efficient format for exchanging the data between server and the web client for things like tables. If using a JEE server, there are java libraries that make it simple to format JSON data ( even convert beans to JSON ) for presentation to the client. Displaying the data on the client ( with a toolkit ) takes a few lines of code.
I've used XML heavily for about five years now, with Java based tools, and XSLT/Xpath, and have really convinced of the data centric approach - but working with JSON has made me rethink a lot without final conclusions yet. The Java based tools are brilliant for making sense of XML documents and converting them. XSLT is great for dynamic conversions on a web page, and fun to work with ( if you're into crazy/powerful expressions ). JSON really strips the document to the bare bones - very minimalist, but I'm not sure the tool-sets are as extensive as the ones Java and XSLT offer for picking out and transforming XML data.
So I agree for now, that JSON is superb across the wire and especially when building dynamic web clients with the Ajax toolkits.
[link]
From: Jeff Payne (Dec 27 2006, at 16:22)
Benja wrote, "But Tim, your argument was that HTML, XML and JSON are widely used and binary protocols are not."
No one was arguing that binary formats aren't widely used or shouldn't be used, just that text-based formats/protocols shouldn't be discounted and, in some cases, are a better choice than binary.
[link]
From: Dave Johnson (Jan 07 2007, at 16:25)
IMO it makes sense to use XML when using a scripting language that is, for the most part, interacting with an XML based markup like HTML. Transforming the XML to another markup like HTML using XSLT on either the client or server is exceedingly simple. Not only is this easier than building an HTML string with JavaScript but it also has performance gains (http://blogs.nitobi.com/dave/?p=68).
[link]
From: Frank Cohen (Jan 10 2007, at 16:33)
Hi Tim: Excellent roundup of several issues. I do take exception to one of your points:
"there aren’t that many apps where parsing and unparsing are a significant part of the workload."
I've been doing performance and scalability work in XML-based applications since 1999 and find that many industries have now standardized around XML schemas for their particular domains. For instance, FpML and FIXML in the financial industry, BOD for automotive retailing, CDISC ODM for clinical trials, etc.
Most of these schemas create large and complex (in terms of hierarchy of XML elements) documents. For instance, the BOD to get a purchase order creates an XML document that when written as a string is 7500 bytes long with no element data filled-in.
When I tested a Web Service written on the popular app servers (WebLogic, WebSphere, JBoss, etc.) using these scemas I found a huge performance effort being undertaken to parse the XML data.
The test, results, and methodology are available under open-source license here: http://www.pushtotest.com/Downloads/kits/soakit.html
Also, given that Java developers have a choice of 13 different XML parsers - each with their own performance characteristics - my experience tells me not to dismiss XML processing from the reasons to go with XML over some other encoding/decoding mechanism.
-Frank Cohen
http://www.pushtotest.com
[link]