OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Why you should not design JSON data models

On Mon, Jul 3, 2017 at 7:47 AM, Ghislain Fourny <gfourny@inf.ethz.ch> wrote:
Dear Ihe,

I partly agree, partly disagree. Here are a few thoughts.

1. I would not discard JSON as a viable syntax for arborescent data, and neither would I discard XML. Each of them has its sweet spots. XML definitely surpasses JSON at document-oriented data. More precisely, I mean here with "documented-oriented" mixed content encoutered for example in the publishing industry (this is different from “document” as in "JSON document" or "XML document”), such as

<p>This <i>is</i> <b>a sentence</b>.</p>

which cannot be achieved with JSON in a natural way. And of course, JSON has its nice sweet spots, too, in particular in the absence of mixed content and when there are more regular patterns in the data.

2. The fact that JSON is smaller/simpler/more lightweight than XML can be advocated reasonably and with objective criteria by, for example, comparing the size of their respective specifications (I mean here the syntax only, not the schema/data model/querying ecosystem around them). An introduction to the JSON syntax (it fits on json.org’s homepage) is definitely shorter than one on the XML core syntax. This is neither good nor bad, as each syntax has their usecases.

I was referring to the size myth extensively addressed by David Lee http://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
but also succinctly debunked in the section

Comparison with other formats(XML subsection) on the JSON Wikipedia page.

3. XQuery was extended in its latest version with maps and arrays (and, as it was a low hanging fruit, support for JSON input/output). This demonstrates that JSON is relevant in the tree-like data landscape, at least as a good complement to XML.
4. Granted, the same “errors of judgement” are regularly repeated when new syntax gets invented: first, one thinks that one does not need all the complexity of existing syntaxes. And then, with time, one realizes that one needs this data model, and that schema language, and that other query language, and an update language, and so on. Still, this realization is a good thing.

5. But the lesson here is, I think, not so much the irrelevance of an alternate syntax, than it is how important it is to look at what was done in the past (SQL, XML technologies, etc) and not reinvent the wheel. XQuery 3.1 and JSONiq are both based on numerous years spent designing XML (and relational tables). JSound (even though we didn’t advertise it much in the community) shows that many features (simple types, some of the aspects of subtyping — not all, ...) of XML Schema make sense for designing JSON schemas. In the end, JSON will/should end up having a similar ecosystem structure to that of XML, because this toolbox is needed for trees just like it is for tables or graphs.

6. I do not see XML/JSON as a step back from the work on relational databases. While in many cases it is desirable to have normalized data, in some others (notably, at much larger scales of data), denormalization makes sense, for example, for performance reasons (it is nothing else than the precomputation of joins). So, XML/JSON can simply be seen as denormalization that even reverts the first normal form. The important part, here, is to know what one is doing, that is, be aware that in many cases, a relational database in third normal form is preferrable to a document store. Some other use cases nevertheless justify denormalizing and using XML or JSON (Or YAML, Apache Avro, Google's protobufs, etc).

I hope it makes sense.

Kind regards,

It makes sense but you are addressing different points.

The issue is not JSON should be discarded - in this day and age that would be a silly argument to even begin to make.

Yes JSON is simpler and more "lightweight" (whatever that means) but it is also far less capable.

I am exercised on things that JSON is not suitable for  like modelling of complex data interchanges  because it's ecosystem lacks the necessary infrastructure precisely because it is too simple and too lightweight but where the tooling arguments made for justifying such extensions/expansions are based on false equivalences.

On 1 Jul 2017, at 09:15, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

Just doing my bit to ensure that some of that conversation gets archived. Nothing to see here - move along.

 #JSON came on the scene and quickly adopted an attitude of "I alone can fix it". Then propagated a bunch of populist myths - #JSON is smaller than #XML (debunked on their own wikipedia page) XML is complex (as if you are compelled to use all of it for everything) and ignoring the fact that much of that complexity derived from the domains it was deployed in.

Everything is justified by "It's simple and lightweight" which is great except they create this expectation that it be deployed for things that are not simple or lightweight.

This leads to the "Nobody could have thought that ...... could be so complicated" and the realisation that you do need schemas, namespaces (i.e all the things XML was condemed for).

However a spirit of "Repeal and Replace" pervades there are no "Good Parts" in anything the "other side" did you end up coming up with your own version , which when scrutinised is

a) found to cater for the interests of one community (Developers) at the expense of every one else. and b) founded on false equivalences - (JSON Pointer = #XPath) and not to sing the praises of #XMLSchema #XSD but try ripping it out and replace it with JSON Schema and see what happens.

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS