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 http://www.json.org/. 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.
