Re: [xml-dev] List of differences between XML and JSON?

Thank you very much, Dimitre, for these explanations. As Thomas pointed out, the data do *not* communicate object identities and therefore your statement that two (JSON) objects represent the same (graph) object is arbitrary. It might be true in the context of an application, but it cannot be upheld as a statement about JSON and its capabilities.

The picture could be changed, of course, by introducing object-identifying data, e.g.

"objectID" : "O104829401759"

And then it would be a serialization option whether to unfold the object data only once, at every occurrence (as in your example), or nowhere. So far, so good, But this has nothing to do with JSON, as these data suggest:

<list1>

<title>TheGiver</title>

</book>

</list1>

<list2>

<title>TheGiver</title>

</book>

</list2>

You might argue that in XML, two <book> elements with the same @graph:objectID are nevertheless two distinct nodes. But I think this is irrelevant: the mapping of nodes (= entities capturing the information found in the markup) to objects in a graph is already the next plane of semantics, and there is nothing to stop us from representing a given object by several nodes.

JSON and XML are both based on containment, and it seems that other relationship can only be expessed by key/keyref data.

So JSON and XML can both express graphs if - and probably only if - including such data. (RDF/XML is an example - @rdf:resource.) You seem to think that JSON is better suited for expressing graphs than XML. That is very interesting, and if it is "true", the trueness would consist in an information model describing the parsing of JSON data into graph data and the serialization of graph data into JSON data. The key question in the context of this discussion would be whether this model would not be compatible with XML data as well. The fact that JSON data can be mapped to XML in a fairly straightforward and roundtrippable way seems to imply this - no?

JSON or XML, not important: the challenge of reconciling the neatness and readibility of trees with the realism of free associations between tree nodes (within- and cross-tree) might be very important indeed.

Cheers,

Hans-Juergen

Dimitre Novatchev <dnovatchev@gmail.com> schrieb am 18:24 Sonntag, 3.Mai 2015:

On Sun, May 3, 2015 at 5:42 AM, Thomas Passin <list1@tompassin.net> wrote:

> Well, actually, there is nothing to indicate that these two objects are the same.

> A _javascript_ engine would create two objects, and if you were to change

> the properties of one, the other's properties would not automatically change.

Agreed. The example, and the way I am using this is strongly based on assumption that the objects are immutable.

We also need to remember, that JSON is widely used not only for representing _javascript_ objects, but also in other important cases -- for example to express the input data for REST web services (seen in practice with the most widely used HTTP verbs) and for their response.

JSON is just a specific serialization mechanism -- how JSON would be de-serialized depends solely on the receiving end -- it may be serialized to something completely different than a _javascript_ object.

Any good particular implementation would use objects immutability for sharing and efficiency.

For the XPath 3.1 map datatype, this is what makes possible to have efficient (sub-linear) implementations of map:put() and map:remove().

http://www.w3.org/TR/xpath-functions-3/#map-functions

Even in a language such as C# there are some immutable objects, such as the string object. This led to a powerful string sharing feature: interned strings: https://msdn.microsoft.com/en-us/library/system.string.intern(v=vs.110).aspx

Cheers,

Dimitre Novatchev