Deprecating XML Volume 13 , Issue 51 ; The X in AJAX not withstanding, XML is not the darling of web API designers.

Someone asked me recently what I thought about XML being removed from the Twitter streaming API. Around the same time, I heard that Foursquare are also moving to a JSON-only API.

As an unrepentant XML fan, here's the full extent of my reaction:

“Meh”.

If all you want to pass around are atomic values or lists or hashes of atomic values, JSON has many of the advantages of XML: it's straightforwardly usable over the Internet, supports a wide variety of applications, it's easy to write programs to process JSON, it has few optional features, it's human-legible and reasonably clear, its design is formal and concise, JSON documents are easy to create, and it uses Unicode.

If you're writing JavaScript in a web browser, JSON is a natural fit. The XML APIs in the browser are comparitively clumsy and the natural mapping from JavaScript objects to JSON eliminates the serialization issues that arise if you're careless with XML.

One line of argument for JSON over XML is simplicity. If you mean it's simpler to have a single data interchange format instead of two, that's incontrovertibly the case. If you mean JSON is intrinsically simpler than XML, well, I'm not sure that's so obvious. For bundles of atomic values, it's a little simpler. And the JavaScript APIs are definitely simpler. But I've seen attempts to represent mixed content in JSON and simple they aren't.

In short, if all you need are bundles of atomic values and especially if you expect to exchange data with JavaScript, JSON is the obvious choice. I don't lose any sleep over that.

XML wasn't designed to solve the problem of transmitting structured bundles of atomic values. XML was designed to solve the problem of unstructured data. In a word or two: mixed content.

XML deals remarkably well with the full richness of unstructured data. I'm not worried about the future of XML at all even if its death is gleefully celebrated by a cadre of web API designers.

And I can't resist tucking an “I told you so” token away in my desk. I look forward to seeing what the JSON folks do when they are asked to develop richer APIs. When they want to exchange less well strucured data, will they shoehorn it into JSON? I see occasional mentions of a schema language for JSON, will other languages follow?

I predict there will come a day when someone wants to federate JSON data across several application domains. I wonder, when they discover that the key “ width ” means different things to different constituencies, will they invent namespaces too?

In the meantime, I'll continue to model the full and rich complexity of data that crosses my path with XML, and bring a broad arsenal of powerful tools to bear when I need to process it, easily and efficiently extracting value from all of its richness. I'll send JSON to the browser when it's convenient and I'll map the the output of JSON web APIs into XML when it's convenient.

JSON vs. XML? Meh.