XML future: evolution or revolution?
The biggest dilemma I see for XML and the related technologies is that their reason for existience is to provide an agreed-upon mechanism for interoperability across platforms and applications. but those agreements are hard to update without breaking interoperability. There are a lot of things that arguably ought to be changed to address problems that have emerged as XML specs have been implemented and used. My previous post mentioned the size of XML messages that creates much resistance in the wireless industry and the parsing/serialization overhead that creates resistance in the enterprise transaction processing sector. Others have noted that XML syntax is difficult for non-experts to produce correctly, and almost everyone complains about the numerous problems in the XML Schema specification.
As John F. Kennedy is widely quoted as saying, "those who make peaceful change impossible make violent revolution inevitable." The problem is that those who make peaceful XML evolution at least difficult are the vast numbers of users for whom it is actually working, i.e. the customers who directly or indirectly pay us. Real users tend to stay away from the nasty corner cases that us geeks whine about,, and would be hurt in the short term by disruptive changes that create incompatibility between products that support different flavors of the XML specs. There is already an XML 1.1 Recommendation which has received essentially no industry support, mainly for this very reason. There is some talk of an "XML 2.0" that will learn from both the technical experience and the procedural experience we have gained, and it is at least possible that this will be more fruitful.
As I see it, the only thing that would seriously motivate the keepers of the XML status quo to change would be a significant threat of "violent revolution" -- a movement towards some new model that hits XML's 80/20 point, leverages much of the thinking (and perhaps a lot of the code) that has gone into making XML a success, but does not strive for backward compatibility. Paul Tchistopolskii has been trying to undermine the XML status quo for some time (he, uhh, used to own the domain "xmlsuck.com"), and has recently updated his list of alternatives to XML. https://www.pault.com/pault/pxml/xmlalternatives.html
At the top of the list is YAML. Over the holidays I was talking with one of YAML's authors, Clark Evans. He said that YAML has a role in Ruby much like the role XML has in the Java and .NET worlds, i.e as the default format for little things such as config files and the easiest way to serialize an object for exchange or persistent storage. This got me thinking ... Microsoft Monitor's #2 suggested New Year's resolution for competitors is "Advocate and unite around industry standards that Microsoft doesn't control". I dunno ... I'm not worried about that -- once it is clear what the real standards are, MS can implement them and offer tools support at a level that is second to none. (The hard part is figuring out which specifications are going to get enough traction in the industry to become real standards). The problem is how to anticipate and work to counter (or leverage -- remember what happened on December 7, 1995) the disruptive innovations that come seemingly from nowhere. Some simple but powerful dynamic language that supports one of the XML alternatives or subsets might do this.
As much as I once thought (and even hoped!) that this would happen, I'm now pretty skeptical that it will happen anytime soon. First, XML, even encumbered by the schema language, is solving a lot more problems in the real world than it causes. Second, most of the XML alternatives are good for one use case -- YAML for data, WikiML for simple documents, but none gets that "not great for anything, but good enough for everything" traction that XML gets, for better or worse. Finally, it has survived and prospered despite (and possibly because of) the ugly bits that I once thought were fatal flaws. It exemplifies the old joke that "a camel is a horse designed by a committee", but then again camels can survive for weeks in conditions that would kill an elegantly bred horse in a day.
Nevertheless, a disruptive innovation that replaces XML could happen, and almost certainly will happen sooner or later; the challenge is figuring out whether "sooner or later" is after we all retire, or sometime much sooner. The even bigger challenge is to determine whether XML can and should evolve to preclude such disruptions over the long term (at a short run cost to some users), or whether it should simply leverage its single greatest strength, the industry consensus that it is good enough in its current form for a very wide range of uses. Your thoughts on that dilemma would be much appreciated!