Re: [xml-dev] XML vs JSON

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

I do not consider myself an "expert" in the comparison of JSON and 
XML, but I thought I would offer my own observations.  In my work 
with UBL we have been pressured to support both syntaxes, much to my 
chagrin and reluctance.  Accordingly, I proposed the JSON 
serialization of UBL that is being successfully adopted in our 
community, but also criticized by others in its approach.  This has 
helped me to better understand my personal feelings about this 
topic.  Your mileage may vary.

I have not reached the same conclusion as you that "JSON's major use 
case is in the use within REST".  As the JavaScript Object Notation, 
I understand JSON's major use case is in AJAX-like interactions 
between programs and the JavaScript in browsers.  In such 
low-threshold and low-latency environments, the mating of in-memory 
data structures between the server and the browser puts the burden on 
the server to arrange the information in a way that spoon-feeds it to 
the browser for quick action.  There is a burden to format the 
information as needed, but that burden is borne by the high-speed 
server rather than the low-speed browser.

I worry that programmers have conflated their personal "ease of use" 
with this targeted benefit that low-speed browsers enjoy by having 
their memory structures quickly populated by such a syntax.  The 
browser becomes an extension of the server.  There is incredibly 
tight coupling in such a solution.

But, horses for courses, a syntax should be used as fit for purpose 
and not be used as a convenience for programmers.  A programmer's 
task is to make their user's job easier, not to make their own job easier.

And I posit that JSON is fit for purpose only for quickly populating 
browser memory structures for JavaScript manipulation in a tight 
coupling between sender and receiver.  I claim it is not fit for 
purpose as a generalized information serialization format where 
decoupling between sender and receiver is paramount.  It may be a 
convenience for programmers, but it is not fit for generalized 
information processing data flows.

In my comparison I have ruled out JSON as a candidate for expressing 
mixed content (sibling element and text content).  I hope it is 
accepted that generalized text processing of mixed content remains 
the domain of XML and such content cannot be efficiently expressed in 
JSON syntax.  I think the only logical discussion is the comparison 
of XML element content (all elements contain only element children 
and possibly irrelevant indentation white space) and JSON structures.

Such is the case for OASIS UBL - ISO/IEC 19845:2015 ... all content 
is element content.  The UBL XML [1] and the UBL JSON [2] 
serializations are guaranteed isomorphic because the JSON is not 
derived from the XML.  Rather, both are derived from a common Core 
Component Technical Specification (CCTS) Version 2.01 [3].  CCTS is a 
modeling approach of business information entities published by the 
United Nations trade facilitation group.

Key in my mind to the difference is the coupling of systems I 
mentioned earlier.  I was taught when learning SGML that generalized 
information processing supports the decoupling of 
systems.  Maintaining independence of one processing system from 
another partner processing system allows either processing system to 
change without impacting its partner.

You cite REST and the REST interface is an implementation of such 
decoupling between systems.  So I feel XML very much has a role in 
REST approaches, and it very much did before JSON came along.  There 
is nothing about REST that favours one syntax representation or the 
other.  In my mind it comes back to the features of the syntax used 
over REST and the fit for purpose.  So I think any discussion of REST 
is orthogonal to a discussion of XML and JSON.

I see the purpose of an independent syntax between dissimilar systems 
is the unambiguous representation of information.  A recipient can 
extract from the syntax all components of the data without using any 
subject-matter awareness.  Once so obtained, the recipient then 
applies the subject-matter awareness (the semantics) to the 
information independent of whatever syntax that was used.

There may be intermediaries between the sender and the recipient.  In 
the business circles where UBL is used, an auditor is an example of 
an intermediary.  It is critical that independent of both the sender 
and the recipient that an auditor be able to inspect the 
content.  This, too, is a two-step process:  teasing out the 
information from the syntax in a manner independent of the semantics 
of the information, and then applying whatever semantics is needed on 
the extracted content.  The auditor's semantics may be different than 
the trading partners exchanging the information, and so the auditor 
needs to unambiguously identify the content in order to apply their 
own semantics.

XML achieves this semantic-free syntactic identification of content 
by the unambiguous labelling using element names and attribute 
names.  The (dreaded) namespace concept is crucial in creating 
world-wide unambiguous labels, but let's not get into that 
discussion.  I am a big fan of namespaces because they solve this 
ambiguity issue, regardless of whether people like or dislike their syntax.

It has been my experience that JSON users seek to abandon the 
labeling of content by inferring the identification of content.  The 
in-memory representation of information in one system is instantly 
conveyed to the in-memory representation of that information in the 
other system.  This can only be done by pre-agreement between sender 
and recipient.  Instantly this engages the need to interpret the 
meaning of content *at the syntax level* and not only at the 
semantics level.  Instantly this disenfranchises third parties that 
may, perhaps even for legal reasons, need to inspect the content and 
determine what information was intended to be conveyed in the absence 
of an unambiguous label.  These third parties may not know all of the 
implicit agreements on information representation short-cuts or 
assumptions that lie in that in-memory structure.

The role of syntax is the identifying of the information being 
conveyed, independent of the semantic interpretation done by the 
programs that act on the information.

Accordingly, my approach to serializing CCTS-based data models in 
JSON is wholly based on the explicit labelling of content.  This 
allows me to write transliteration applications between XML and JSON 
syntax for all CCTS-based models (UBL or any other) without any 
awareness whatsoever of the semantics behind the syntax.  Such an 
approach with JSON lead me to the use of objects and keys for 
distinguishing sibling content under different labels, and the use of 
arrays for distinguishing sibling content under the same 
label.  Addressing the content becomes rote and semantic-free through 
the dot and array notation working one's way through the unique key 
labels and the counted like-named siblings.  In effect, it is a 
generalized syntax using JSON notation.

This has led to criticism of the approach as being too verbose and 
not in the spirit of JSON for programmers.  The actual quote in [4] 
is "processing code is a mess".  I feel the response [5] to this 
successfully defended the design decisions in the CCTS approach to 
all of the points made in the analysis. Regardless, this attitude 
towards JSON has led the group of programmers to promote an 
alternative localized serialization of UBL in JSON that is based on 
agreed short-cuts and associations.  Thus, a third party inspecting 
such serializations must know, a priori, what those assumptions are.

I acknowledge the same can be said for assumptions about the 
semantics of information between the sender and recipient after the 
information has been teased out of the syntax.  But that is not my 
point.  My point is that the syntax itself should be a semantic-free 
labeling of the content for the unambiguous transmission of the data 
from the program of the sender to the program of the 
recipient.  There should be no semantic triggers in the syntax that 
would impact on how the information in the syntax is to be 
identified.  Semantic interpretation should only happen after the 
information is identified.

The tight coupling between the server and the browser that lead to 
developing JSON promotes a tight coupling between sender and 
recipient when JSON is used for generalized information 
interchange.  This, in turn, promotes the need for prior agreement 
and a tight coupling of representations in the computer systems of 
sender and recipient.  Independence between systems is lost.  In 
fact, the information interchange is no longer generalized.  So JSON 
is fine when the information interchange does not have to be 
generalized, but it has to be coerced in order to be used in a 
generalized fashion.

And many real-world scenarios of information interchange must be 
generalized in order to decouple the systems involved in that 
interchange.  The international interchange of business information 
is the other end of the wide spectrum to the server populating a 
browser's in-memory data structures to speed up the browser's 
response to user keyboard interaction.

So to summarize my overall personal perspective: if JSON has to be 
coerced into having the same expressive generalized labelling 
features as XML already has, what is the benefit of having used 
JSON?  It *can* work as I have shown it to work for UBL, but it was 
not designed to work in the fashion needed to be generalized.  How 
does reinventing the XML processing stack for JSON advance the 
objective of the interchange of data between dissimilar decoupled 
systems?  And XML already handles mixed content and element content.

I keep getting back to horses for courses:  use XML for generalized 
interchange and use JSON for the tight binding between systems 
sharing identical in-memory representations.

I firmly believe the job of the programmer is to take on the burden 
to make the user's task easier or better.  It isn't responsible for a 
programmer to take the easy way if it adds effort to the users or 
takes away features from the users.  My father, a programmer, taught 
me this long ago.

I hope this perspective is helpful to your thoughts in this regard, 
Mukul.  No doubt others will feel differently.

. . . . . . . . Ken

[1] http://docs.oasis-open.org/ubl/UBL-2.1.html
[2] http://docs.oasis-open.org/ubl/UBL-2.1-JSON/v1.0/UBL-2.1-JSON-v1.0.html
[3] 
http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/Business-Document-NDR-v1.1.html
[4] https://lists.oasis-open.org/archives/ubl-comment/201705/msg00007.html
[5] https://lists.oasis-open.org/archives/ubl-comment/201705/msg00011.html

At 2017-08-01 17:04 +0530, Mukul Gandhi wrote:
> Hello,
> I don't intend to spark a bitter debate between XML & JSON, where 
> the outcome of debate is win of one over other. Rather, I wish to 
> present in a friendly manner, according to me, where these two 
> technologies differ.
>
> When talking about designing REST services, JSON seems to clearly 
> win. The whole software world seems to be biased in favour of JSON 
> it seems, for this criteria. Although I have read, that in many 
> cases REST services can use XML instead of JSON. I think, JSON's 
> major use case is in the use within REST.
>
> Having worked quite a bit with Android mobile apps, that framework 
> by default relies heavily on XML. I haven't seen JSON being used by 
> default in that area. Although, JSON is many times used in feeding 
> and fetching JSON data from various kinds of services (remote REST 
> services, local API calls etc), in Android apps.
>
> XML when considering other technologies in combination, like XML 
> Schema and XML databases, have a scale close to RDBMSs. JSON is no 
> where near this.
>
> Any other thoughts from the experts here?
>
>
>
> --
> Regards,
> Mukul Gandhi

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |