|
Hi,
There is another major difference between typical JSON models and XML models (somehow related to parent pointers): JSON trees have labels (keys) on their edges, while XML trees have labels (element names) on their nodes.
One aspect of parent pointers is that a parent node then “owns” its children exclusively (1 to n rather than n to m relationships in the subsuming graph). This was at the core of the discussions in the design of XQuery 3.1 and is one of the aspects
that distinguishes it from JSONiq.
The differences between these two approaches, to me, is much less related to the XML vs. JSON discussion than to the use case relevant to a user. If the trees (regardless of XML or JSON) are meant to be stored in a document store, then it consideraly
simplifies the model to assume that a parent owns its children (copy-on-insert) because this is much easier to serialize and store.
JSONiq, which has this document-centric approach, could in theory be extended to support parent pointers and upward navigation because of its document-based approach. It does not do so yet, because downward navigation was predominant in the use
cases, and because the absence of upward navigation allows to both (i) save memory and (ii) optimize downward navigation (streaming).
XQuery 3.1 was optimized for the use case of in-memory management of maps and arrays (no copy-on-insert, i.e., preservation of node identities in map and array constructors) and for this reason — not because of JSON itself, as I am trying to advocate—
cannot be extended to support upwards navigation. As Mike states, it “makes certain kinds of transformation more difficult to express, but […] other kinds of transformation much more feasible.” There is no right or wrong, only decisions motivated by use cases.
Kind regards,
Ghislain
It would probably be a good idea to re-read the FtanML proposal at
I don't think it got everything right, but I think it contains some good ideas along these lines.
At the level of tree models I have come to realise that there is a fundamental difference between XML tree models and JSON tree models that has nothing to do with the differences in syntax: XML trees have parent pointers, JSON trees don't. As
I tried to show in my XML Prague paper last year, this has surprisingly far-reaching effects on the design of a transformation language.
Michael Kay
Saxonica
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'
{
"name":"Rick", "age":856, "city":"Sydney"
}
>Hello •<b>World</b></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 <json> 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 Jelliffe
|
