[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]


  • From: "Ghislain Fourny" <gfourny@inf.ethz.ch>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Fri, 18 Aug 2017 14:57:21 +0000

Re:  XML vs JSON
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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.