>
> Any JSON object can be part of (shared by) many other JSON objects.
This seems to be part of the JSON back-story rather than something that is evident in the JSON specification itself. JSON has no intrinsic, natural way of expressing types, type hierarchies, networks/graphs of instances, or anything like that.
In fact, there seems to be a paradox here. To represent a graph efficiently, you really need some way of labelling the nodes in the graph, that is some concept of identity. And yet our data models for XML seem to have a stronger notion of identity than our data models for JSON.
>
> The ability of any JSON object to be shared amongst any number of
> other JSON objects is what makes it possible to have very efficient
> modification of a JSON object (compared with complete
> copying+modifying of an XML document, to create an entirely new,
> non-overlapping XML document). In the former case, only the paths
> leading to the modifications need to be copied in the new object, all
> other sub-objects can be shared between the old and the new JSON
> objects.
>
Yes, that's true, but I don't think it's a consequence of the JSON grammar or the XML grammar.
We've made choices in the way we model XML for processing, for example we provide a parent axis so when you are at a node, you can find its parent. That's convenient for many kinds of processing, but it makes it very hard for two XML trees to share a subtree, which makes it expensive to make small modifications to a large tree. We've made a different choice for JSON processing: we've chosen not to provide parent pointers, which means that subtrees can be more easily shared, but other kinds of processing become more difficult.
I don't think there's anything in the BNF of XML or JSON that made those different design choices inevitable.
Michael Kay
Saxonica
