Re: [xml-dev] use of JSON instead of XML

On Wed, Jun 27, 2018 at 1:20 AM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:

. The XML folks can learn from the simplicity of JSON format, and can design simple XML formats for specific requirements, and JSON folks can learn from XML about how to scale JSON solutions for complex requirements for which XML is seemingly suited.

No they can't and no they can't.

Most of the propaganda about XML's relative complexity and bloat is generated by pretending that the XML corollary of a JSON name value pair is an element when it is in fact an attribute, by postulating that namespaces and schema are mandatory when they are not and by claiming that one is more readable than the other when in truth the only entities that have a definitive preference for perceiving data as arrays and objects are developers and _javascript_ programs. The lower impedance offered in the latter point is the real sweet spot and that lesson has been absorbed - what else is there to learn?

Coming to the other side the notion that JSON can or is suitable to scale on the complexity plane is based on this false equivalence ascribed to the two. Here is a simple illustrative example of what can happen when you simply take an XML based product and say - I want a JSON version of that.

If you go to this link you will see a recent addition to the NIEM toolkit - Movement - which is supposed to allow you to create a subset NIEM exchange in JSON.

https://beta.movement.niem.gov/#/results?q=*

However many of the NIEM elements cannot be added to a JSON subset because they are not simple types (as in the simple vs complex type XML Schema sense) . You can see this because they don't have an adjacent Add To Subset blue button. If you click on the elements in question you will see that only elements defined as simple types have a blue button next to them.

This means that you cannot add fundamental NIEM elements like PERSON or ORGANISATION with such a tool and it seems (to me at least) to throw the whole idea of NIEM conformance out of the window since the tool prohibits you from selecting NIEM Core elements necessary to create a conforming document.

Ok one can get into a bout of so-whatism on that but I struggle to see how suddenly enabling a completely different exchange format into a community that for the best part of 15 years has been XML based exchanges contributes to the mission of "a common vocabulary that enables efficient information exchanges across diverse public and private organizations" (lifted from https://www.niem.gov/). How are users of this information exchange supposed to adapt to the sudden perhaps unexpected receipt of a JSON (conformant?) message. What useful need is being filled here to justify the extra work that all data exchange recipients will now have to do.

This is not so much about criticising NIEM , they have their reasons for doing this, one of which was they felt it was necessary to maintain relevance. The point is to show shortcomings in the end result that are solely and completely attributable to the fact that JSON, the chosen exchange format does not have equivalent capabilities to the one it is replacing.