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

XML "failed" on several fronts, from the perspective of developers:

1) The XML DOM model was too complex. It had originally been designed as a way to create a low level library from which higher level libraries could be written, but those higher level libraries never materialized. 
2) Namespaces should have been designed more intuitively. Namespaces are not unfamiliar to developers, but in most cases it's possible to import namespaces so that they are shared under the same rubric in languages such as Java. That was never an option with XML, and it meant that most XML documents became a cacophany of prefixes. 
3) The presumption of containment proved deadly. XML eventually developed a streaming model, but it was a decade too late. Browser vendors found that if they had to wait for XML to completely load before it was processable, this proved to great a strain on browsers of the time. 
4) XPath 2.0 never made it into the browsers' XML implementations, and consequently neither did XSLT 2 or XQuery, all of which were orders of magnitude better than their first versions. This kept the technology firmly on the server side.
5) E4X was never allowed to take off. It could very well have changed the course of development, making XML far easier to use on the browser, but political pressures within the W3C, browser vendors and the ECMA community conspired to kill it. 
6) XML was also a casualty of the war between the philosophy that HTML was a language that could be extended given a suitable extension mechanism and the philosophy that HTML was a "sacred language" that could only be set by WHATWG and allied groups. Once the latter became the de facto position, XML was pretty much excluded from the browser. 
7) Simon's points earlier indicate another critical reality - the community of _javascript_ REACT developers is larger than the number of XML practitioners at this point by a considerable margin, and REACT uses an "XML-like" language that is syntactically a mess, probably because they don't know any better and have no intention of rectifying this fact. Most of us who still play in the XML world are on the upper side of fifty; the average REACT developer is 27, and likely has never even worked with XML.

JSON is not necessarily a superior language for most data interchange, but it is in essence a security blanket for anyone who works in the web world (or within mobile app development, which is moving heavily towards _javascript_). XML is a Lincoln Town Car - big and luxurious and powerful, but something that no one under the age of 35 would drive if they can help it.

Kurt Cagle
Founder, Semantical LLC

On Mon, Jun 25, 2018 at 6:02 PM Patrick Durusau <patrick@durusau.net> wrote:

Right track? Not having explicit semantics?

The popularity with programmers can't be denied but is that the measure
for "right track?"

Like spaghetti COBOL code, a lack of explicit semantics is a key to long
term employment, but I don't see that as a good thing. (Not to single
out JSON, the documentation protocols for Hadoop and family are based on
C. Yeah, way to go.)

Authoring angle-bang syntax isn't the difficulty in using XML, although
it is rumored to be verbose. It's choosing and adhering to a consistent
semantic that's hard.

Hope you are at the start of a great week!


On 06/25/2018 08:26 PM, Simon St.Laurent wrote:
> 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
> _______________________________________________________________________
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Patrick Durusau
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

[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