XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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.

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.

You see the problem is that what should happen is that the JSON community should say  - right if we want to use JSON in XYZ context we need to upgrade our ecosystem so that we can support it.

Instead what I see happening is JSON advocates demand JSON support without contemplating whether or not they have the prerequisite infrastructure.

The receiving body then decides that if they don't jump to the beat they are at risk of becoming irrelevant and so eventually cobble together some hotpotch of a compromise which is the best they can do.

Now everybody else using the product/model has to figure out what features were compromised/disabled in case they have to send or receive a packet in JSON form.

It's like being made to teach Calculus to students who refuse to bother learning the prerequisite algebra



[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