[Dimitre Novatchev:XSL-List] Understanding JSON: Why JSON and XML are Incompatible and Why You Should Care

by M. David Peterson

Dimitre Novatchev recently posted the following to XSL-List, something of which I thought would be of both interest and benefit to those of you in Land-O-XML who care about things kinds of things. As such,


2008-05-16 12:58:36
M. - can you point out he link? I did a search on the mailing list and could not find it. Also, I not a guru on jsON, but I can not think of any JSON that I can not transform and back. Do you know of any examples? Hell - I can convert a CSV to XML and back so why not json?
2008-05-16 13:12:14
hi ric,

I think the idea here is of being able to always go from any XML representation to a JSON representation and from the JSON representation back to the same XML representation from which you started.

From the description it also seems that it should be generic. I think in most cases of data-centric XML documents that most developers will encounter a format-specific mapping can be achieved, given that one can with certainty say that one controls both steps - for example if I know that the JSON I had came from XML of a particular format then I should probably be able to round-trip it.

2008-05-16 13:26:06

Thanks for the clarification - it makes sense now that he is looking for the GENERAL pattern for ALL json to xml.

I have a head cold today so I am a little slower than usual


Kurt Cagle
2008-05-16 23:03:06
JSON suffers from two fatal limitations in terms of the mapping, something I've discussed before in this space. The first is the fact that a JSON {} object requires that hash keys be unique: {a:foo,b:bar,a:bat} is illegal in JSON. I've seen attempts to get around this with the use of arrays, but these become convoluted quickly:


for instance, while legal, is no longer as simple. This has to do with the fact that JSON assumes that a hash key and a unique identifier are one and the same, while XML makes no such assumptions. In any but the simplest of JSON entities (those in general that have clear mappings to relational data tables), the complexity in expression rises quickly. This complexity is unbounded - successive "roundtrips" between XML and JSON will cause the JSON to increase in "size" geometrically while XML remains stable. While I haven't seen Dmitri's formal reasoning, I'm sure it runs along much the same lines.

I actually use that as a test to determine the degree to which a given XML structure is data-centric vs. document-centric. A completely data-centric XML-structure has an isomorphic JSON mapping (the JSON doesn't grow, or, put into metric terms, would have a mapping of 0 ((j[n+1]/j[n]) - 1). The rate at which JSON tokenization grows could thus be used as a rough metric indicating the "document-centric" nature of XML content. The example above would have a metric of ((25 chars/19 chars) - 1) or 32% growth.

Note that if you relax the one unique property per object boundary and introduce two "named" symbols - @ for attribute and # for namespace, you could produce a JSON-like notation for XML:

<html xmlns="http://www.w3.org/1999/xhtml">
<title>This is a test.</title>
<h1 id="foo">Test</h1>
<p>First line of test</p>
<p>Second line of test</p>

could be represented cleanly as:
{title:'This is a test'},
p:'First line of test',
p:'Second line of test'

However, this wouldn't parse in any JSON parser.

This is a case where the data models between the two languages are different, and where XML is actually a superclass of JSON, not an equivalency.

M. David Peterson
2008-05-18 08:10:54

Please see: http://www.oreillynet.com/xml/blog/2008/05/jesper_tverskovxsllist_more_on.html as a follow-up response.