Monday, 24 January 2005
JSON and XML
Then, by defining mappings to other languages (e.g., Java, Perl and C#; by coincidence or design, Python doesn’t require anything extra), they suddenly get a data interchange format that’s pretty darn useful for what’s becoming a very common task — turning those browsers into an application platform.
Some XML people will scoff, whilst others will have fear in their eyes; as discussed before, XML isn’t so great for data modeling.
It Always *Starts* Simple…
So, will XML be a distant memory in a few years? Will world-wide inventories of angle brackets shoot up thanks to JSON? Not quite. While on the face, it’s a very attractive solution, I have a feeling JSON is going to run into a few problems.
First of all, it’s still a tree; there isn’t any way to represent a graph in JSON. This isn’t a big loss over XML — also a tree — but it does present a problem in some situations. It would be better if a reference mechanism were built in.
More seriously, JSON also doesn’t have a language-neutral schema mechanism; while you might be able to describe something in prose, or in a language-specific way, it would be really nice to be able to validate data and generate code, and it’s critical to have well-described interfaces.
Next, JSON’s type system is fairly limited; for example, there are no time or date types. You can say that it’s an integer offset from an epoch, but then you get into implementation-specific concerns. Whoops.
Don’t Get Cocky, XML
That’s not to say that XML is so hot either; while these problems have been recognised, XML can’t represent a graph, XML Schema is not exactly user-friendly or even implementer-understandable, and while the XML Schema type system is pretty good, extending and versioning XML is still dangerous territory, and Namespaces in XML are trickier than they appear.
So, although JSON clearly has shortcomings and limitations, XML shares some of them, and extracts an arguably high tax for those it doesn’t.
Considering that it’s tangentially associated with oh-so-cool technologies like GMail and Google Suggest, and is a sop to the XML-is-too-slow-and-bloated contingent, I wouldn’t be surprised if, once mature, JSON takes a bite out of a lot of the “low-end” (translate: non-enterprise) projects out there, because XML will fail to justify its cost in non-markup applications. In short, some developers won’t care about the limitations above, because they don’t think they’ll push the envelope that much, or if they do, they can fudge it. Fair enough.
That said, right now I still think of JSON more as an expression of frustration with XML for data modeling and representation than the ultimate solution; while it’s extremely attractive to couple it closely with existing languages, more is required to interchange data robustly between distributed systems. YMMV.
The “O” stands for “Object.” Here we go again…