OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] use of JSON instead of XML

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS