In a follow-up conversation to the post made by Dimitre Novatchev, Jesper Tverskov provides an excellent summary as to why XML and JSON are incompatible. He goes on to describe several functions in XSLT he feels would help alleviate at least some of the pain, but to keep things focused on understanding the incompatibilities between XML and JSON, I’ve left them out. When XSL-List archives todays conversations, I’ll update this post with a link to his comlete post.
However, before I provide his summary, I want to quickly provide some of my own thoughts on the XML -> JSON <- XML discussion which I provided in follow-up to a comment made by Robert Korberg,
On Sun, 18 May 2008 08:04:26 -0600, Robert Koberg
> Bottom line - there is no standardization. If you want to do xml2json
> and json2xml you pick your library and write for it.
I agree. Furthermore I believe the notion of converting XML and JSON to and from each other is the wrong approach altogether. Instead I believe the emphasis should be upon creating a standard format for JSON in which can be referenced and queried by XPath in such a way that regardless of whether the incoming format is XML or JSON, the same XPath applied to both will result in the same generalized result set.
In fact, if not mistaken, this is what Mike Champion and friends have been discussing over in the MSFT camp for several years now, which makes sense when you look at what they’re doing with LINQ-to-*.
Jesper’s summary follows in-line below,
As I have found out from the “XSL in the AJAX world” thread,
there are several issues in xml2json transformation and in json2xml
1. As seen from Google’s use of JSON,
and from Stefan Goessner’s article, Converting Between XML and JSON,
property names in JSON could begin with characters not allowed as
first character in XML like “$” (used by Goggle) and “@”, and “#” used
by article. I find it strange but not surprising that even in JSON
only “$” works in both IE7 and Firefox. “@” only works in Firefox, and
“#” not even in Firefox!
The bottom line is: some characters are allowed as first character in
JSON but not in XML making even the most simple json2xml
transformation problematic: the maker of the function must find a way
to deal with illegal characters in XML.
2. JSON has no way of handling even the most simple document oriented
XML structure like: “h2, p, h2, p” if the order matters as is likely
in the example. In JSON the order of the example will be changed to:
“h2, h2, p, p”.
3. JSON has no standardized way of handling attributes. Attributes
will most likely be converted to what could just as well have been an
element or some prefix character will be added signaling that this was
originally an attribute. This prefix depends on who made the
conversion function, making it impossible to convert back unless a
similar function is used understanding the meaning of the prefix
4. JSON has no standardized way of handling mixed content.
Theoretically the most simple mixed content could be handled with a
method similar to handling attributes but the prefix characters needed
to tell text and element apart depends on who made the function. If
mixed content consists of more than one text node and one element we
run into the reordering problem.