Issue No. 04 - April (2012 vol. 45)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MC.2012.132
Charles Severance , University of Michigan
Crockford is careful to point out that he didn't invent JSON—rather, he simply discovered it, and told us all about his discovery when I recently spoke with him about JSON, XML, and the future. You can watch the video interview associated with this article at www.computer.org/computingconversations.
I decided that if I wanted to be able to use this thing [JSON], I needed to make it a standard, so I bought json.org and put up a webpage and declared it as a standard. That's it. That's all I did. I didn't go around trying to convince industry and government and everybody that this is what they should do. I just put up a one-page website. Over the years, people discovered it and realized it was so much easier [to use JSON].
JSON versus XML
If you've worked as a programmer in the past decade, you've witnessed the constant background debate about whether XML or JSON is the right format for data representation. XML was always the well-understood "enterprise solution." An extensive toolset was available for working with and manipulating XML, there were sophisticated mechanisms for precisely defining the XML schema, and developers could use extensive libraries to create and parse XML. Since the mid-1990s, XML seemed like the safe and obvious choice for data representation and interchange. Industry support for it was broad and well-organized, whereas JSON had one webpage and one man making presentations around the world about this cool idea.
So why, then, is JSON slowly displacing XML as the preferred way to serialize and exchange data? Why is the underdog winning? According to Crockford,
It's not that curly braces are so much better than angle brackets. Ultimately, none of that matters. The thing that mattered was that the data structures that JSON represents are exactly the same data structures that programming languages represent.
In other words, the point is less about the particular syntax of JSON versus XML but more that for moving internal data structures from one program to another, JSON has a natural advantage as a serialization format.
When Ajax was formulated, the "X" in Ajax was supposed to be XML, and the smart kids right away realized this [XML] is too hard: we don't want to be doing XML. Some of them discovered that they could use JSON instead, and that it was so much easier and so much faster. For a while, there was a debate [about whether to use XML or JSON in Ajax], but that didn't last very long.
Even though JSON seems to be winning as the most natural data transfer representation when communicating from one program to another, developers continue to view XML (and HTML) as the best representation for document-style information such as word-processing files or webpages. Clearly, there isn't a perfect, one-size-fits-all solution for data representation, but at least for now, JSON is dominating program-to-program data transfer.
Once programmers make the switch to JSON, they seldom switch back to XML for their program-to-program data serialization needs. But inevitably, as more programmers start using JSON, the call for new features such as the ability to define a schema for a JSON object grows louder.
An early example of this trend to add value is the "JSON Media Type for Describing the Structure and Meaning of JSON Documents," which Kris Zyp put forward as an Internet Draft Request for Comments before the Internet Engineering Task Force ( www.json-schema.org). The approach in this document doesn't change JSON—rather, it simply adds some conventions within the existing JSON syntax to define schema details.
This ability to add value to JSON without altering it is an essential feature, according to Crockford:
Probably the boldest design decision I made was to not put a version number on JSON so there is no mechanism for revising it. We are stuck with JSON: whatever it is in its current form, that's it. And that turns out to be its best feature. Because it is a basic infrastructure—it's the thing that you pile everything else on—it's equivalent to an alphabet in a language. We might make up lots of words and lots of ways of creating sentences, but it's very uncommon to make new letters. And that's the place where JSON lives, so it's good that it's not going to change.
Another effort that adds value to JSON without changing it is "JSON for Linked Data" ( www.json-ld.org), which adds simple extensions to JSON so that it can easily represent large linked data structures typically represented via RDF. Like the JSON Media Type, JSON-LD is an extension that works without changing the JSON structure. In a sense, JSON-LD is just another language using JSON as its alphabet.
JSON is moving from being an underground secret, known and used by very few, to becoming the clear choice for mainstream data applications. But perhaps what's most exciting is the value-add capabilities that will become part of the developer's toolkit as JSON increasingly takes over the heavy lifting of data encoding and interchange.
Charles Severance, editor of the Computing Conversations column and Computer's multimedia editor, is a clinical associate professor and teaches in the School of Information at the University of Michigan. Contact him at firstname.lastname@example.org. You can follow Severance on Twitter @drchuck.