To me it is clear that XML and JSON have complimentary strengths. And I would go further to suggest each needs what the other provides in order to be the most useful. It is not likely, but I put up an idea XMON on the XML-DEV mail list this week, which has some interesting discussions.
Here is a tweaked version of my initial post.
XML was ascendant for 10 years and overhyped. The second 10 years of its life its has been descending to be merely used where it is appropriate, which is the best any technology should hope for. Classic hype cycle, I guess.But in order to thrive, I think it needs to grow and morph into something more. What is the low hanging fruit, that would give a great increase in functionality with the maximum ability to connect to existing technology by small shims?
I would suggest it is to embrace JSON as doing a different but compatible thing to
elements and content (apologies if I am just repeating someone else’s suggestion):
lets prune and embrace!
<?xmon?>
<!-- Example -->
<some-element xml:id="me" class="plenty"
{
"person": {"name":"Rick", "age":856, "city":"Sydney" }
}
>Hello •<b>World</some-element>
<?checksum 0x12356775756?>
I.e., UTF-8, DTD-less, namespace-less XML allowing some well-defined version of JSON
in start-tags after attributes. Prefixes useable for open standard vocabularies.
Not WF XML or JSON, but trivially convertable to XML by putting the JSON into an first element or to JSON by pulling in each fragment, or whatever. But the intent would be to use an extended DOM with JSON nodes.
It allows JSON to be used with mixed content and schemas. The XML parts can be accessed with XPath as usual, and so Schematron, RELAX NG, XSD etc come along for the ride. I expect XSD would be overkill, in that you we can use syntax to express the type rather than needing some kind of post-schema-validation-infoset.
Regards
Rick
And later (tweaked)
In XMON XML parts are XML and my JSON parts are JSON. To me, the XSLT JSON/XML exchange reeks of the same problem that XSD had: it tried to solve a syntax problem by larding on concepts and markup. Which is not to predict failure, at all.
That is why I think an extended DOM/XDM is necessary, the ideal approach for XSLT for this kind of thing is for XPath to add a special axis for accessing unnamed ‘elements’ (if it is JSON as content in XML,) or unnamed ‘attibutes’ (for XMON syntax.)
The proper treatment of JSON isn’t to convert it to elements. It is to convert it to structs (are arrays and maps…fine) but then to be able to step through them with XPath, surely. Abbreviated syntax is the glory of XSLT.
For example,
/top//container/#[1]//taxnumber
Where # means an embedded JSON struct and the second // is operating in JSON only.
Several other XML-DEVers from the open standards and open source world wrote in with ideas in this direction they had had.
XSLT’s Dr Michael Kay raised two conferences presentations he had made:
- FtanML is his attempt to incorporate JSON and XML, taking the queue of making simpler end-tags.
- Transforming JSON using XSLT 3.0 on the intrinsic differences between the XML and JSON tree models.
Dr Hans-Juergen Rennau, whose FOXPath is about extending Xpath to above the level of the document, recommended the BaseX function json:parse which imports a JSON struct into XDM data structures to allow direct XPath manipulation.
XQuery’s Dr Ghislain Fourny of ETH Zürich suggested that XPath elements have the label on the node, while JSON has labels on the edges.
XForm’s Alain Couthures, who has implemented his ideas in JS, agrees on the idea of extended DOMs (or, more likely, I agree with him!) and reminded us of two of his papers in this area:
Many posts were excitivated by changing the syntax of XML: rather like how George “The Animal” Steele would be distracted by eating the turnbuckle at critical moments of his wrestling matches. I think it is a trap and a snare, but what do I know (by the way, George had a Masters…):, but generally discussion on syntax is lethal, smiilar to how discussing concrete markup rather than information models with domain experts can be lethal to getting things done…
I tend to think that merely replacing one syntax with another is as big a waste of time as is possibly: and I think one of the central reasons for XMLs success was it prevented syntactic distraction by Mrs Palm and her five lovely daughters.XML suffers from a lack of syntactic forms to signal underlying types. JSON is useless for status-classifying information (along XML’ s content/attribute/comment/PI quartet) and for mixed content, of course. So let’s combine them, retaining their syntax, taking the opportunity to rid XML of big things it doesn’t need now (DTDs, encodings).
While on the topic of XML and JSON, note the subsequent post on XPath 3.1;