{"20thCentury" :[ {"title" : "To Kill a Mocking Bird",
"author" : "Harper Lee",
"year" : 1960},
{"title" : "The Lord of the Rings",
"author" : "Tolkien",
"year" : 1954},
{"title" : "The Giver",
"author" : "Lois Lowry",
"year" : 1993}
],
"90s" : [ {"title" : "The Giver",
"author" : "Lois Lowry",
"year" : 1993},
{"title" : "American Psycho",
"author" : "Bret Easton Ellis",
"year" : 1960},
{"title" : "The Notebook",
"author" : "Nicholas Sparks",
"year" : 1996}
]
}
This JSON object represents a set of two (named/labeled properties) small listings (collections) of famous books. The name-of /label-to each property is "20thCentury" and "90s". Each of these two collections is a JSON object itself, and the name/label that it is referred to from the outermost object, is not part of the collection object. The labels serve as links/references from the referencing to the referenced objects.
The collection object doesn't know that it is referred to in another object and labeled as "90s". In fact, the same collection object could be referred to by another object using a completely different label, say: "John’s favorites" and thus shared between these two objects. Each collection object is an array of other JSON objects, each of which represents a book, and each such object has properties (labels) named "title", "author" and "year". The values to which this labels refer are not themselves JSON objects (may be thought of as leaf nodes in a graph, or terminal (literal) symbols in a grammar)
None of the book objects inside of the collection objects knows that it is used in an array and that it has particular "neighbors" in particular order.
Now, notice that the book object representing "The Giver" by Lois Lowry, takes part in both collections. This is another example how two different JSON objects share a single third JSON object.
One could argue that these are two different JSON objects that happen to represent the same book. This is not true, because these "two objects" cannot have their own different data and if we want to change, for example, the year when the book was written, we must make the change in both of these "two objects".
To summarize: this example shows:
Hi Dimitre,you write: "JSON is typically used to express a set of objects and the connections (links/edges) between them, without restricting how many links point to the same object. This makes JSON convenient for expressing directed graphs."Could you explain? How can one express connections (links, edges) using JSON? (Except for, of course, interpreting some values as IDs and others as ID references, in an adhoc way which can be done in XML as well.)I am at a loss. My starting point is RFC 7159. These are the data types: object, array, number, string, boolean, null.Cheers,Hans-JuergenDimitre Novatchev <dnovatchev@gmail.com> schrieb am 22:12 Samstag, 2.Mai 2015:
On Sat, May 2, 2015 at 12:24 PM, Costello, Roger L. <costello@mitre.org> wrote:Quoting Hans-Juergen Rennau> Why would one want to apply XQuery concepts to JSON?>> Hence Dimitre's statement that in JSON subtrees can be shared makes (to me)> only sense when equating JSON to a particular information model. (Which one?> XDM maps/arrays? _javascript_ objects?)Both XML and JSON instances are just a sequence of characters. This is it -- without adding to such a sequence of characters some more or less well-defined meaning. This meaning (semantics) can be quite formally defined -- as is the case with the XDM, or it may not have a formal definition, but still exist, defined by the common ways people use the language.> But, but, but … the XDM is, as far as the XML specification is concerned, a fiction. That is, as far as the XML specification is concerned,> all this XDM verbiage about nodes and
> trees and axes is pure fiction.This is not a fiction, because this is the meaning people put behind the sequence of characters. It is the meaning, that is important -- there might be many different ways to express the same meaning, and we wouldn't care too much about the specific representation as long as it expresses the same meaning. It wouldn't be a "fiction" even if the sequence had meaning only to Martians... (ask the SETI folks ... :) )So, my quoted statement above can be paraphrased into an equivalent statement: JSON is typically used to express a set of objects and the connections (links/edges) between them, without restricting how many links point to the same object. This makes JSON convenient for expressing directed graphs.On the other hand, XDM formally defines one (and so far the most commonly used) meaning behind a syntactically-valid (as XML) sequence of characters:- "Each node has a unique identity" http://www.w3.org/TR/xpath-datamodel/#node-identity- "Within a tree, document order satisfies the following constraints:
The root node is the first node. Every node occurs before all of its children and descendants" ... etc. http://www.w3.org/TR/xpath-datamodel/#document-order- "The dm:parent accessor returns the parent of a node as a sequence containing zero or one nodes. It is defined on all seven node kinds." http://www.w3.org/TR/xpath-datamodel/#dm-parentAs we can see, according to this formally defined semantics, an XML document represents a document-node and this document node is the root of a treeIf we call this formal definition "a fiction", we could probably proclaim everything posted into this forum as "a fiction", and going further -- even the whole Internet and even anything represented in written form. The fact that you and I are reading this forum means that we probably disagree to perceive it as "a fiction".So, Roger's question about "the differences between XML and JSON" isn't about the differences between two fictions -- it is about the differences of the meaning that the instances of these two languages are used to express.Roger, could you please, agree or disagree with my understanding of the question?--Cheers,Dimitre Novatchev