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
