Re: [xml-dev] XML's greatest cultural advantage over JSON

[Steve Newcomb <srn@coolheads.com>]

On 04/29/2013 07:12 AM, Andrew Welch wrote:

> That is essentially it - processing xml using javascript in the
> browser was hard, processing json was easier.   It's all about the
> apis.

For me, it's all about the data.  Data have (unknowable) value
irrespective of any software.  Machines (and existing transformations)
are by no means the only consumers of data.  They may not even be the
most important ones.  (But importance is a matter of perspective, really.)

A Mediawiki development person asked for public comment about the
possibility that Mediawiki would abandon XML in favor of pure JSON.  I
responded (see below), attracting no significant interest.  However,
when I offhandedly pointed out, as a side issue in a later note, with a
very brief and realistic code example, that JSON invites code-injection
attacks in Python environments, the guns came out.  XML, after all, is
not a programming language, whereas JSON is a proper subset of Python,
modulo a very few keywords like "null" -> "None".  I thought it was a
side-issue, but evidently it's a sore point.  Interesting.

--------------------

The below remarks are extracted from the documentation of a tool we use
in our consulting practice, which includes data management/publishing
services for U.S. government customers.  The extract is from a
discussion of how the tool can optionally format XML for
human-readability *without* polluting the data with spurious new
whitespace.  Then it digresses to more general considerations in a NOTE
which is directly relevant to the JSON vs. XML question.

It all boils down to a simple question: will the data ever be used
outside its current known applications and/or software?  If the answer
is "No", then JSON is probably the right choice.  If the answer is
"Yes", then XML is certainly a better choice, but then the questions
arise: "Whose perspective on the data should be baked into it?", and
"Who will pay the cost of baking it in?"

All best wishes for you and for humanity's ongoing invention of
civilization, which depends on the longevity of knowledge,

---------------
     Note: Needless to say, both syntaxes, XML and JSON, have
           advantages and disadvantages.  In the context of this
           discussion, it may be worthwhile to highlight the essential
           difference between JSON and XML, which is that XML provides
           (demands, really) an explicit distinction between data and
           data-about-data (metadata), while JSON does not.

           In other words, XML requires specific classes of things to
           be endowed with names, while JSON imposes no such
           constraint.  XML offers a standard way of unambiguously
           distinguishing the names of classes of data, and the names
           of attributes of those classes, from the data themselves.
           These names must be chosen somehow.  Normally, the chosen
           names are meaningful.  The choice of a specific name by a
           human being is the making of a semantic commitment.  Thus,
           in XML, data are expressed in a way that almost inevitably
           reflects how someone (perhaps even the author!) thought the
           data should, or at least could, be understood.  JSON, by
           contrast, does not demand that such a perspective be
           explicitly embedded in the data.  If such a perspective is
           embedded in JSON data, JSON does not provide a standard way
           of abstracting that perspective from the data.

           But neither syntax prohibits the processing of data in terms
           of a data/metadata perspective other than the one(s) that
           were embedded in them.  Whatever information XML can convey,
           JSON can also convey, and vice versa.  However, if a
           data/metadata distinction needs to be baked into the data,
           such as when the data may need to be understood by a human
           being apart from any specific software application, XML is
           simpler to use, and the baked-in data/metadata distinction
           will be universally understandable as such, not only because
           of the World Wide Web Consortium XML Recommendation, but
           also because of ISO International Standard 8879-1986, as
           amended.

           If a baked-in data/metadata distinction is not desired, JSON
           is pretty clearly the better choice, but then at least two
           questions arise:

               (1) Are you certain that an embedded data/metadata
                   distinction will be undesirable for all future
                   applications of these data, including applications
                   that do not yet exist?

               (2) Are you certain that you wish to forego your
                   opportunity to influence how these data will be
                   understood, including by persons as yet unborn?