[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: use of JSON instead of XML

• From: Michael Kay <mike@saxonica.com>
• To: Kurt Cagle <kurt.cagle@gmail.com>
• Date: Tue, 26 Jun 2018 08:58:40 +0100

> On 26 Jun 2018, at 07:06, Kurt Cagle <kurt.cagle@gmail.com> wrote:
> 
> XML "failed" on several fronts, from the perspective of developers:

Agree with this absolutely: though one must never forget there are other fronts where XML remains a spectacular success.
> 
> 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.

Some higher-level libraries (LinQ, jQuery, ElementTree) have been quite successful, but they never quite solve the problem of marrying up two very different views of data, the XML view and the programming-language view.

It's certainly true that the poor usability of DOM, especially in the Java world, is responsible for a lot of the negative perceptions.

>  
> 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.

Yes, I said right at the beginning that namespaces were a disaster, and I still hold that view today. Their cost in added complexity is far greater than their value.
>  
> 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.

I'll think about that one. 

>  
> 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.

And not just the browser vendors. The big technology vendors (Oracle, Sun, Microsoft, IBM) all did lots of XML tooling in a mad frenzy of enthusiasm from 1998 to 2002, and then lost interest, largely, I think, because having established an expectation that the software would be free-of-charge, they weren't able to put together a business case for further investment. And the open-source weekend enthusiasts who put together products like libxml lost interest too, very understandably: for how many years do you want to spend all your spare time producing free lunches for people making fortunes on the back of your efforts? But the situation with the browser vendors was the worst, because they had exclusive control over what was available on their platforms, so there was no room for third parties to fill the gaps.

> 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.

Perhaps, I'm not sure.
>  
> 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.

To put it another way: the browser platforms were essentially a monoculture; there was no room for development of alternatives and competitors to the core technology delivered by those who controlled the platform. It's only when you get a platform that's open to third parties that you get a healthy level of competition and innovation.

>  
> 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.

I'm sceptical of quantitative data like this that's based largely on anecdotal evidence. It's notoriously difficult to get reliable data about what's actually happening in our industry. Our perception in Saxonica is that XML usage is still growing, including use in new projects, but it's moved from adoption by the noisy freelance 25-year olds to adoption by the quieter, more mature, and bigger projects where it ends up being part of the unseen IT infrastructure that our daily lives depend on. Those projects don't tweet so much, but they are real.
> 
> 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.
> 

Certainly XML has ceased to be a fashion accessory. Which is probably a good thing.

Michael Kay
Saxonica

• References:
  • use of JSON instead of XML
    • From: Mukul Gandhi <gandhi.mukul@gmail.com>
  • Re: use of JSON instead of XML
    • From: Peter Flynn <peter@silmaril.ie>
  • Re: use of JSON instead of XML
    • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • Re: use of JSON instead of XML
    • From: Patrick Durusau <patrick@durusau.net>
  • Re: use of JSON instead of XML
    • From: Kurt Cagle <kurt.cagle@gmail.com>