JSON isn't XML

Joe Gregorio

After avoiding JSON for a long time I am finally getting around to looking at it. The reason I'm just now looking is that the specification is now available as an informational RFC without the funky license that plauged the original. Yes, licensing matters.

The first thing you notice when you look at JSON is the simplicity. It certainly hits its target as a "lightweight data-interchange format".

JavaScript Object Notation (JSON) is a text format for the serialization of structured data. It is derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard, Third Edition [ECMA].

JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).

And I was happy to see a clear and simple character encoding story for JSON, which is Unicode in one of UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE), all of which is detectable by looking at the first four octets. Contrast this with XML.

The XML we wanted

It appears that JSON is the XML that many people wanted. For proof of that just look at XML Schema. But JSON is a data structure serialization, as opposed to the markup language that is XML, and could probably do just fine with a schema language, which could define some more data types based on the primitives that are present. For example, there is no native JSON datatype for a date/time, and that's probably not something you want to define on an application by application basis.

All of this looks good except for the extensibility story which Mark Nottingham has already covered. With no baked in extensibility story you will end up with a real world experiment in the viability of 'short names'. On the other hand JSON qnames will work like most people (mistakenly) expect them to work in XML. You might end up seeing: 


[
  {
  "u":"http://patricklogan.blogspot.com/2006/09/getting-it-through-not-understanding.html",
  "n":"Tim Bray on Ruby...",
  "dc:Date": "2006-09-25T10:55:47-05:00",
  "d":"Making it stick.: Getting It Through Not Understanding",
  "t":["humor","python"]
  },
  {
  "u":"http://www.washingtonpost.com/wp-dyn/content/article/2006/09/23/AR2006092301130.html",
  "n":"I hate it when that happens.",
  "dc:Date": "2006-09-24T20:00:31-05:00",
  "d":"Spy Agencies Say Iraq War Hurting U.S. Terror Fight - washingtonpost.com",
  "t":["politics"]
  },
  ...  
  }
]

There are, of course, plenty of opinions on whether a system of 'short name' disambiguation can reliably prevent conflicts and still be fair:

I have no idea how this 'short name' experiment will end for either JSON or Microformats, but it certainly bears careful watching.

When to use XML vs JSON?

JSON isn't XML and fills a gap that XML was being stretched to fill. The strengths and weaknesses of the formats need to be taken into consideration when deciding which to use. If you are transporting documents or are aiming for a wide range of extensibility then you should be using XML. If you have control over both ends of the wire, for example, talking to your own web server from HTML pages served from that same server, then you should be using JSON. Everything in between will require some judgement.

Of course, old habits die hard and one of the first specs that uses JSON is JSON-RPC.

But you can still use JSON RESTfully, right?

Yes you can ...

comments powered by Disqus