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

["Simon St.Laurent" <simonstl@simonstl.com>]

On 6/25/2018 5:59 PM, Peter Flynn wrote:
> > My personal feeling is, that people would choose XML when they're
> > developing a big software instead of a tiny one. And when good
> > software engineering is important.
> If this is true, then the software industry is in a worse state than we
> imagined :-)
I don't think this is about flawed software engineering.  The JSON folks 
seem to me to be largely on the right track.

JSON had the advantage of arriving (technically, being abstracted from 
JavaScript) after XML's trajectory had become clear. XML began as a 
simplification process - XML a reduction of SGML, XSLT a reduction of 
DSSSL, XLink a reduction of HyTime - but it didn't stay that way.

XML showed the spectacular possibilities of text-based formats for 
exchanging information, throwing communications doors open to people 
well beyond the usual suspects of protocol design.  That part was 
amazing, and people suddenly realized the possibilities that had quietly 
existed just outside of respectable core programming knowledge.

Unfortunately, the XML community's response to all of this interest was 
to sprout endless committees to build new tools to let XML do even more 
of that.  XML sprawled as it piled on schemas, graph notations, query 
languages, and anything else we could come up with to be all things to 
all people.

Though further simplification had its fans in the core XML community, I 
can't say it was a particularly respected position among the people 
running the visible projects.  "Extensible" apparently applied to the 
core specs more than markup in practice.

Programmers groaned under the complexity and the intrinsic mismatch of 
markup structures and programming structures.  Along came Douglas 
Crockford with a ready-made solution!

JSON's status as an extraction spared it the endless extensions, and its 
source meant that it was a natural fit.  It was data structures for a 
programming language, and nothing more.  (By happy coincidence it was 
also effectively a subset of YAML, the one other project of its kind to 
get traction with programmers.)

JSON has - much more cautiously - evolved more formal specifications, 
schema languages, and many varieties of tooling. (At least one of the 
participants in that, Tim Bray, is familiar from XML.)  JSON messages 
and JSON-based APIs are sprawling across the Internet and beyond, but 
the core set of knowledge needed to work with JSON has stayed manageable.

Yes, there are at least two cases where XML is a better choice:

* I wince when I see documents represented as JSON, especially if anyone 
ever has to work on the JSON directly.  Markdown and asciidoc are better 
choices for those allergic to markup, even. Limited, yes, but extremely 
useful.  I see document parts as JSON constantly, in APIs that would 
have been smarter just to send HTML fragments.

* It is certainly possible to create systems that are complex enough to 
need the tools of XML Schema and friends to present a complete 
description of interchangeable data structures. Unfortunately, we tend 
to forget that these projects are outliers, not the kinds of projects 
that most developers build or even need to interact with at that level.

XML started out as a sleek lifeboat escaping from SGML.  Somehow we kept 
bolting on more and more.  While the results were pleasing to a certain 
crowd, XML wound up desperately top-heavy, an easy target for the 
lightweight JSON fleet.

Sometimes you need a battleship.  Most people don't.

Thanks,
Simon