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

Re: Why you should not design JSON data models

  • From: Ihe Onwuka <ihe.onwuka@gmail.com>
  • To: Ghislain Fourny <gfourny@inf.ethz.ch>
  • Date: Mon, 3 Jul 2017 22:22:08 -0400

Re:  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]


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.