Re: [xml-dev] XML vs JSON

["Ghislain Fourny" <gfourny@inf.ethz.ch>]

Dear Ihe,

I just have a few spontaneous comments.

> 
> The last sentence in the above definition begs a number of questions. 
> 
> 1. Does it then follow that a data format should ONLY be based on those 2 structures.

I agree with the difficulty to justify “only", however for JSON’s defense, these two structures (arrays and associative arrays) are pervasive structured types in arborescent data formats: even in XML, you can view attributes as an associative array mapping strings to simple types, and children of an element as an array of items. But also YAML, protocol buffers, etc, and even in some relational databases as structured types.

Now, to (on purpose) contradict myself, these structures are only two (maps, lists) of many abstract data types (sets, multisets, stacks, queues, and so on). Maybe maps and lists play a more fundamental role in data storage and exchange, while the others play a more fundamental role in computations and algorithms as intermediate containers?

> 2. If a data format such as XML, or RDF deals has programming language support for the data structures they deal in why should JSON supplant such formats and their usage.

Both XML and JSON are out there and widely used, and both have their specific sweet spots. I think that we need to accept it rather than try to push one against the other.

RDF is a totally different animal and serializes graphs, not trees. It is orthogonal to XML and JSON, in that RDF both exists as RDF/XML, JSON-LD, and many others. Here too, I think that which RDF syntax is chosen is secondary to the higher-level RDF, triple-based, data model. It is like making a phone call: as long as I can talk with a colleague and the voice is properly sent through, I do not mind which telecommunications protocol it is sent over.

> 3. A relational database is not a programming language and a relation is neither collection of name/value pairs nor an ordered list. So why should my relational database speak JSON.

There is a natural mapping from tables to unordered collections of (flat) trees expressable as JSON (or XML). Viewing a relational table as JSON opens the door to denormalization below the first normal form, as you start nesting structured data in lieu of atomic values. It is thus a natural way of importing a relational table into a document store.

Likewise, a relation with a primary key (even compound) can be logically seen as a collection of name/value pairs.

Data shapes (tables, trees, graphs, cubes, text) are like different kinds of arrangement of matter and offer perspectives: strings, quarks, atoms, molecules, crystals. They all matter and play a different role, interact in different ways, giving us some flexibility in data storage and processing. We can switch from one to another quite easily or build one on top of another. Syntax is a bit like writing down a molecule with a chemistry formula, such as representing an amino acid with Cs, Hs, Os, Ns and the like. What matters in the end is not the way its structure is written down: it is its very essence as an amino acid.

I guess what I want to say is that data models should be first-class citizens, not syntax, I feel it is a bit the spirit of Edgar Codd’s point on data independence, stretching it a bit.

Just my 2 cents.

Kind regards,
Ghislain