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,
> I have the nice FXSL function, f:json-document(), working but I am
> wondering if it can transform any JSON generated from XML back to XML?The short answer is that there isn’t a 1:1 mapping between XML and JSON.
This means that there isn’t a function
f : XML Document —> JSON Object
such that
((f)-1) . f = f . ((f)-1) = id
Here I use ((f)-1) to denote the reverse function of f(), as I cannot
use superscripts in this plain text format.FXSL uses the JSON grammar as published at http://www.json.org.
The JSON grammar in RFC 4627 is much more loose and describes a JSON
object that does not correspond to an XML document and even not to
what the value of an XSLT 2.0 variable may be (secuence of items of
any type), because for example it allows a named object to have an
array of unnamed scalar (let’s say integer) children.People need to be aware of the whole JSON hype and not be easily lured
into substituting it for the stable and proven useful by years of
practical experience XML document representation.Any claims of better readability of JSON become obviously wrong for
any but the smallest size JSON objects.
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?
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.
@Bryan,
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
Ric
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:
[{a:foo},{b:bar},{a:bat}]
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">
<head>
<title>This is a test.</title>
</head>
<body>
<h1 id="foo">Test</h1>
<p>First line of test</p>
<p>Second line of test</p>
</body>
</html>
could be represented cleanly as:
{html:
{head:
{title:'This is a test'},
body:
{h1:
{@id:'foo','Test'},
p:'First line of test',
p:'Second line of test'
},
{#:"http://www.w3.org/1999/xhtml"}
}
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.
@*,
Please see: http://www.oreillynet.com/xml/blog/2008/05/jesper_tverskovxsllist_more_on.html as a follow-up response.