Skip to Content

Is XML dead? Are the Browser Wars Over?

Call it luck, brilliance, or none of the above, but in 1998, we chose XML as the foundation of our “Illuminator” (now SAP xMII) product when I founded Lighthammer.  So, almost 10 years later, I’ve been reading a lot lately about how XML’s popularity may have peaked, and that its universality for all kinds of applications may be in question.  First of all, I think both schools of thought are correct.  Any attempt to fit a single paradigm to all kinds of application areas (UI, A2A, service enablement, data management) is likely to be a compromise at some level.  XML has had a huge positive impact on providing a human readable, platform/language/transport neutral way to render information.  While there hasn’t been much progress on consistent ways to actually render that information within XML, it still has had a very positive effect.  With the advent of web services, XML took on a multidimensional role – both as the description language for defining a web service and as the transport medium (in most cases) for the web service.  I, for one, have never believed that web service = SOAP + HTTP + XML.  That type of narrow definition does not fit.  We’re already seeing extensive interest in REST-style service consumption – something that has been integral in xMII from its inception – plus there are now many different formats for the “payload”.  xMII allowed web services to return data, images, documents, etc. – in a variety of formats, from XML to CSV to HTML to binary.  One format that is getting a lot of hype these days is JSON (Javascript Object Notation) – you can learn more at  JSON is becoming quite popular for consuming data in web client applications, typically AJAX-based, but not exclusively.  I’ve been experimenting with JSON a bit lately, and have create some extensions to xMII to render its output in JSON format.  And my first impressions are favorable.  One of the goals of JSON was to provide a (mostly) browser agnostic way to address the data structure, without all of the ugliness of XPathing, node walking, and other things that were needed to do similar things with XML data within a client app.  If any of you have ever tried to invoke and process a complex web service from AJAX, you’ll appreciate what a complete mess it is.  In any case, JSON’s syntax allows a friendlier approach, as in:  results.PurchaseOrder.Item[2].ShipTo.Address  Javascript-based implementations of JSON (note: JSON’s format is not implicitly javascript-based – implementations for other languages are available) work with most major browsers available today.  While evaluating JSON, I noticed some similarities to work I had been doing with Adobe Flex and Apollo (which are very impressive tools).  Flex 2.0 added support for a script-based mechanism for dealing with XML data called e4x, which is basically JSON++ and is an ECMA standard (ECMA is best known for ECMAScript, which is the foundation for Javascsript).  e4x provides a similar syntax to JSON, but also enables the use of XPath-like selection criteria for selecting groups of data elements or individual elements as in:  results.PurchaseOrder.Item[PartCode=’ABC123′]  That’s all good, but from a practical perspective, very few browsers support it natively.  Notably, IE does not have any support for e4x (even with IE7).  In my view, the perfect solution would be for all browsers to support e4x, but as we all know, the world ain’t perfect.  This reminds me a lot of the Scaleable Vector Graphics (SVG) standard.  It added a HUGE amount of functionality to the client side of web applications – did you know that there are no browser-based ways to draw a circle?  Sounds trivial, but it is a big gap in the browser-based UI that led to lots of really, really ugly hacks over the years.  SVG addressed this quite nicely, but as with e4x, only limited browser support was ever realized (Microsoft has two SVG-like things already, with VML and, in newer OS’s, XAML/WPF).    Nevertheless, once again, we’re teased with a great solution to our problems, but because of political BS and “not invented here”, we’re stuck with no real workable solution.  So getting back to the original questions, has XML peaked in popularity and usage?  I don’t think so.  I think what we need to see, however, is better tools (like e4x) for dealing with XML data.  I would also really, really like to see more pressure on the browser makers (OK, mostly one of them in Washington state) to embrace things like e4x and SVG.  But I won’t hold my breath, since they’re taking a different approach to web/rich client applications.  I also hope that the broader community will start thinking about web services as much more than SOAP.  SOAP, to me, gets in the way as often as it helps.  It was designed largely for programmers as another RPC mechanism – but in the mashup/Web 2.0 era, we need a different paradigm for service definition and consumption.
You must be Logged on to comment or reply to a post.
  • Hi Rick:

    I’m not a big fan of XML, so I haven’t work to much with it…But I know as you state in you blog, that newer technologies are taking some ground from it…

    Also, as far as we don’t get a standard for Web Browsers…I think that all web related technologies are going to fall sooner or later…

    As XML replaced Idocs…What’s going to replace XML in the future???



    • “What’s going to replace XML in the future” – if we knew the answer to that one, we could be very, very wealthy… 😉

      Hard to say.  In the end, I think there will be many wire formats and invocation protocols, depending on the consumer and provider, and the type of content.

  • Rick, great post! I would love to hear more about some of the things that your group is experimenting with in these different technologies.

    As for XML, it’s hard to say whether it’s reached some sort of peak or not. As you say, web services <> SOAP, but really just XML in some form at the core. Being that there are no hard rules for XML structure and it being simple plain text, I would say XML is in for the long run right along with HTML. Even if there are true use cases for serialization, we may start to see binary XML formats gain popularity:


    • Hi, Ed.

      We’re already doing some things with binary serialization that results in a BIG TIME performance boost.  Not only because of the reduced size and time-on-the-wire, but because the content can be streamed (send data item/receive data item), rather than build-XML-document-item-at-a-time/send-XML-document/receive-XML-document/parse-XML-document/navigate-XML-document-item-at-a-time.

      I would even make the argument that web service need not be XML.  I consider a web service that returns a dynamic image, JSON content, a PDF report, or whatever, to be a web service.

  • Hi Rick,

    I think JSON is great and everybody should read the short JSON spec: – it’s a good example that a spec can be easy and understandable. But if I read the endless JSON vs. XML debates an the web the first thing that comes to my mind is: Do we really have to reinvent the wheel one more time? Yes, XML has its weaknesses and I can understand everyone who thinks it has a horrible syntax – and in some areas JSON does a great job. On the other hand hand XML has advantages, too (see for example). Up to now I don’t see a reason to bury XML – I think a coexistence is possible.

    The question whether different concepts of web services will be able to live together is much more difficult because millions of dollars are and will be spent on the web service architecture. Do you think several concepts can coexist? Do we really need a change because JSON is neat or because the SOAP/WSDL/UDDI trinity has its weaknesses? How do think about web services?


    • Hi, Tobias.

      E4X, to me, holds lots or promise, and greatly mitigates the XML vs JSON argument.

      As describe in my other comments, I do not think web services should have the narrow definition of SOAP/WSDL/XML.  Any invocable service via a URL, regardless of what it can provide, is a web service, isn’t it?

      Interestingly, there is some cool work going on to provide WSDL-like description language for REST-style web services…

      – Rick