News Stay informed about the latest enterprise technology news and product updates.

What's the future of XML?

by Jack Vaughan

We should know that no technology fits all jobs over all times. But I will admit I thought XML might come close. The ‘X’ stands for ‘eXtensible,’ after all, so it seemed to have a natural mechanism for adaptation.

The idea that it had data-centric, document-centric and program-centric uses was disarming. It was clear it was not a natural developer favorite, of course. It provided the impetus for Web services, SOA, RSS, bioinformatics and much more. But, like Pick or Fortran or other once-popular languages, it is conceivable that XML’s use will at some point decline.

I came to this rumination last week as I caught Yahoo Architect and JSON originator Doug Crockford tell “The JSON Saga” to an audience at The Ajax Experience (TAE) conference hosted in Boston by TechTarget (’s parent company). “The JSON Saga” is not quite up there with “El Cid” or “The Song of Roland” but, in Crockford’s able telling, it is quite a story.

When he discovered JavaScript Object Notation–he shuns the term ‘invented’–it was as a really useful means for browser-server and interservice communication. JSON was kept simple– simple values (numbers, strings, Booleans), simple sequences of values (arrays, vectors, lists) and a simple collection of named values (object, record, struct, hash, proprietary list). Its use continues to grow.

JSON use was driven by Asynchronous JavaScript And XML (Ajax). But, in many ways JSON was a reaction to complexity arising around XML. Such complexity did not make sense in simple Web applications.

The name Ajax was catchy, but, in fact, tons of Ajax apps are written today that never go near XML. The “X” in Ajax is fading. Some would say Ajax and XML have forked. At the same time, those simple Web apps are growing in complexity.

At TAE, Crockford took some shots at XML. He quotes an original XML Working Group Technical Lead, James Clark, saying “Any damn fool could produce a better data format than XML.” Crockford has the right to be critical of XML; he has taken some bitter bashing from those in that camp.

As he surveys the Web as a platform, Crockford sees much that can be accomplished without XML. The upsurge in REpresentational State Transfer (REST) over HTTP shows he is not alone. Yet, XML is at the heart of many software services, and more XML goes into production every day. What do you think is the future of XML?

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

The simple always moves to complex until a renovation attempts to remove the complexity The old is always replaced by new. Often, the new is just something old with a few wrinkles removed.
When I got into the IT world 20+ years ago, EDI was the way businesses communicated with each other. When I started reading about XML in the mid to late 1990's, the prophets predicted the demise of EDI because XML would replace it. EDI is still here and in use though not near as much as it was 10 years ago. XML just couldn't completely replace EDI. The role of XML will in no doubt eventually subside but I seriously doubt it ever going completely away. Over the years I have seen a lot of new ideas that would "transform" development and how we use computers. In retrospect what I have seen is new trends, some stuck and some fell by the way side. Where the new is cost effective and makes since then use it. Where it doesn't, well stick with what works.
[B]XML is a development-language not a runtime language [/B] XML has got a lot of tool-support and a whole lotta money has been invested in this technology, so it won't disappear very soon. But I think the fundamental mistake that has been made is that we started considering XML a runtime language for intersystems-communication instead of a development-time language. While it makes sense to define messages and transformations using XML-related technologies, it doesn't make sense to use XML for the actual communication that takes place. Better technologies like JSON or IIOP have been developed for that purpose.
Tring to get standards across the IT spectrum has and will remain challenging. In the construction industry there has been a push to embrace XML and demand it in all construction software for the transactional data that is now commonly exchanged in paper documents. New, faster, easier and innovative solutions are always there...we call them disruptive because they upset the efforts put forth by our own IT experts. XML will stay for the short term but I suspect it will not be permanent.
The problem with those dumbed down communication protocols is that they don't keep any types, ANY types, not even real, integer, or anything except string. So when you talk about "JSON was kept simple– simple values (numbers, strings, Booleans), simple sequences of values (arrays, vectors, lists) and a simple collection of named values (object, record, struct, hash, proprietary list). " it sounds misleading because JSON is a simple dictionary list of key-value pairs and strings on top of that. Now plz tell me how to send an order object or an invoice object over JSON without getting into a mess.
JSON is for process, XML is for data...
I have also been in IT for over 20 years and worked with EDI, XML, raw data, IIOP, etc. JSON does not ease implementation. In fact, it is more complex to read the output than XML. The statement that XML is data is correct. But the idea that XML based systems will be replaced by IIOP pr even JSON seems a bit odd to me. XML is text therefore compressible without degredation or loss of information. It is still human readable (both a strong and weak point) throughout the transmission process. And, ultimately, it is (as the name implies) eXstensible. Yes, for web front ends, JSON is a good fit. However, in practice, that does not negate the use of XML. It is easy enough to transform XML to JSON with a simple method call that adds no more overhead to a server than an XML Transformation using XSLT. I would caution everyone not to get distracted by bright shiny objects. There are so many security risks that are introduced by new technologies. XML has been around long enough that many of the security issues have been addressed. And, in a SOA, the WSSE and XML Encryption add the levels of security necessary for robust, survivable, scalable, and sustainable architectures necessary to deter weekend hackers and script kiddies. True, implementation of those components in the WSSE is painful and can cause network traffic to increase (as you gather things like x509 certs from a PKI). But in the end, the goal is to have something that is easily understood by your developer, network architect, and network security groups.
We've just had this debate about SOAP web services using XML vs RESTful services using JSON. This is just history repeating itself. Whenever it gets too complex or onerous the developers throw the baby out with the bathwater and "invent" something "lightweight". It's only lightweight because they left all the bits out that got added because they were needed like security and interface definitions. Take a look at Spring now. How lightweight is that after they put all the stuff in there that was in J2EE? There is no way I am going to open up my applications to accept JSON without quarantining the payload and examining it first for malicious Javascript embedded within the JSON. At least with XML I can have the schema validate the payload first and apply security policies to the service interface. What would some malcontent 'script kiddy' try and attack first? A hardened web service with a policy that specifies a complicated set of SAML assertions or some cobbled up REST service that he/she can fire a bunch of requests at with JSON payloads designed to exploit buffer overflows.