|
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.
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,
Ghislain
|