The State of XML

Nothing Too Ambitious

I will, however, say a few words about XML's past development, and what's going on at the moment.

The Past

XML was, and continues to be, a revolutionary technology. Tim Bray likes to say that XML came in "fast and low and under the radar," taking the world by storm. Since then we've seen it explode from a minority interest to a pervasive technology.

However, since those first days, very little has come in "fast and low," and the road forward has involved some very hard work from those sitting on standards committees -- to which I pay sincere public tribute. Real successes of the last few years include XSLT and the XML DOM. Other specifications have been more frustrating in their pace of development -- XML Schemas come to mind here.

It's definitely worth analyzing why the really successful specifications have worked. I'm convinced that a key part of it was in open source implementations, developed in parallel with the specifications. (A couple of days ago I heard Brad Husick talking about the CPExchange group, and mentioning that part of their deliverables was an open-source reference implementation, something I heartily applaud.)

At some point we need to proclaim that core development on XML is at an end. Nothing has had quite the impact of XML 1.0, and one feels that W3C development of XML specifications is gradually getting mired as the requirements of XML users grow disparate, and the financial interests in XML grow larger.

The Present: XML Is About Money

Now that XML has hit the big-time, there's a lot of money flowing into it, and into companies basing their businesses on it. This is a good thing, and testament to the value of an interoperable syntax. However, we need to see interoperability going all the way, and XML being more than a "buzz-word" to gain acceptance for a product.

Users need to realize that just because a product uses XML, it is no guarantee of either interoperability or openness. You may be aware that on XML.com we have conducted XML 1.0 conformance tests using the suites developed by OASIS and the US NIST. In our last round of tests we found the big vendors -- Oracle and Microsoft -- lagging a significant amount behind various open-source XML parsers.

The inference here is obvious -- vendors with a platform lock-in don't view interoperability with as much importance. As users though, we need to demand it. Poor interoperability even at the most basic level limits who you will be able to do business with, and increases your costs of communications. Until we really start demanding conformance, we won't get it.

I welcome the continuing work by OASIS on conformance, and look forward to seeing the work from the XSLT and XML Schema conformance groups.

Yet the onus isn't just on the vendors. If standards bodies create specifications too impenetrable or complex to completely implement, there's little chance of getting true interoperability as the cost of implementation will be too high for vendors. There seems a real risk of this happening for XML Schemas. Standards bodies must ensure their work is usable by implementers, or it defeats their purpose.

Another observation I'd like to make on the use of XML today has to do with its relationship to the network and communication. The majority of XML transfers are point to point, under known contracts. This becomes important to recognize in the context of the future.

The Future: XML = Boring?

We want the XML of the future to be boring. It's true! What those building communication infrastructures on top of XML require is, above all, stability. XML's economic engine is becoming established, and more and more of the standardization activity is in applied horizontal standards (e.g., ebXML) and vertical industry-specific vocabularies.

To quote once more Tim Bray, "XML is the new ASCII" (or, as this is Europe, the new ISO Latin 1). I can testify to this personally -- as editor of XML.com I receive many news releases. For some, their only significance is that they use XML somewhere as a data format -- the product may be literally anything. Nobody expects to press-release saying they've used the ASCII character set -- this is why I am more than a little cynical about XML being used as a marketing buzzword.

Seriously though, we are reaching the point where the XML core needs to stop growing and developing. Some great things are happening in industry collaborations and vertical standards, and these need a stable base.

However, not everything is boring. I'd like to look at an alternate future, and some of the technologies I think will play an important part in the next phase of XML's life.

The Real Future: XML and the Network

XML belongs to the network

From its inception, XML has been inextricably tied with the network, and with the Internet in particular. Its close bond with the URI spec has made sure of that. However, at the moment XML is much more common inside Intranets and in point-to-point business relationships than as a format widespread on the Internet.

Fun things happen when it gets out of control

We've seen with HTML that when things get out of hand, we can have a lot of fun and a lot of innovation. Yes, it's horribly messy. I'm sure many SGML users here both rejoiced and were dismayed simultaneously at the success of HTML (not exactly the most elegant of SGML applications).

With XML on the Internet, we need to reach the "HTML point," where the rewards and complexity of use are sufficiently balanced to see widespread deployment. I don't think this means XHTML, initial indications aren't that optimistic for a quick uptake on XHTML, and the reward over using just normal HTML is not sufficient to cause a landslide of adoption.

What is really exciting me about XML at the moment is the prospect of decentralized, distributed XML. I want to examine first distributed applications that use XML as their connectors, and then move on to distributed XML data.

SOAP

You will all know that an XML application called SOAP is causing a lot of excitement and comment at the moment. Simple Object Access Protocol (developed initially by Microsoft, DevelopMentor, and UserLand Software, and since having added IBM to the list of authors) provides a protocol for routing data in between applications using XML.

Although it is the fashion among the cognoscenti to de-emphasize it, one of the most important features of SOAP is that it will allow remote invocation of program code using just HTTP and XML. This particular use of SOAP as RPC is anathema to long-standing and experienced developers of Internet protocols and distributed systems.

However, SOAP allows the desktop to escape on to the Internet. Application services that previously ran on your machine (a mail service, a directory service) can now be anywhere on the Internet. Applications have a Web-wide communication channel, without much overhead on their part.

This is both good, and bad. Good, as we will see more and more integration with the Web and XML from programs, and some interesting new ways of programming using the Internet. Bad, because there are associated confusions and risks with using SOAP as an RPC mechanism. One thing that worries me is that SOAP users won't design their messages independently from their code -- leading to lock-in, fragmentation, and semantic erosion. You lose your interoperability as soon as you let your SOAP messages mirror your internal data structures.

If SOAP takes off, though, I can't help feeling that the nay-sayers will be in the same position as SGMLers over HTML. It may suck, but it's doing something revolutionary.

SOAP & distributed applications

The SOAP future distributes logic around the Internet. This raises the possibility of not just open-source, but open-service. Applications will be able to make their functions freely available to callers. This could possibly be seen as a greater democratization of programs than open-source itself, as ultimately less technical ability may be required to use these open services, and the platform shouldn't matter. There are some interesting possibilities around using the equivalent of the Unix pipe to chain together and integrate disparate applications into one view for the user.

Yet this view of the future is still a little dull. It's moved the desktop playing field to the Internet, but it hasn't really escaped the point-to-point pre-determined modus operandi that we currently have. How do we reach something that's truly Web-like?

[1] [2] Next