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