deutsche Version
 

Expert Opinion

The myth of a 
universal XML solution

About the Author: Michael Champion is a member of the W3C's Document Object Model Working Group and co-editor of the core XML portion of the DOM Level 1 recommendation. Champion is currently a senior R&D advisor for new technologies at Software AG.

The XML world has benefited from a year or so of "hype" in the press, but we are now seeing some signs of backlash, similar to the bursting of the hype-fueled stock market bubble. Well-regarded publications such as PC Week have published articles with titles such as "The basic failure of XML is its premise."

Just as Java was over-hyped, then torn down, then resurrected in popular opinion over the last five years, we are likely to soon see a spate of articles aimed at deflating the "XML hype." Most of these will stress the proliferation of vertical market-specific B2B exchanges and the lack of rapid progress by horizontally oriented standards bodies such as the World Wide Web Consortium (W3C), OASIS, and even BizTalk.org. It seems like a good time to take stock of what XML ever promised in the way of universality and what it can realistically deliver.

First, one must face facts and admit that some prominent people in the software industry have helped set astronomical expectations for XML, and it is the sworn duty of journalists to point out the gaps between hype and reality. While there is nothing technically wrong with this enthusiasm for XML, hyperbolic statements often gloss over the substantial amount of work it takes to agree upon and implement all the schemas, stylesheets, and code. Similarly, statements such as these don't mention that XML is just a common platform-neutral syntax, and still requires hard work to map semantic concepts from one application to another. Exaggerated statements make it easy for the audience to believe that off-the-shelf XML technology is a much bigger part of the solutions than it is in reality.

Furthermore, it would appear that some commentators and journalists think of "XML" as a universal e-commerce data format, or perhaps a global repository of consistent business data formats hosted by xml.org or BizTalk.org. Several recent articles use phrases such as "the Tower of Babel" and "increased balkanization" to describe the current state of XML, which certainly bears little resemblance to this vision. Yet XML was in fact a reaction against the "one size fits all" SGML DTDs, especially HTML. XML is named the extensible markup language because its designers intended to make it easy for specialized communities to evolve their own, customized data formats underneath the XML umbrella.

So, what does XML really offer the B2B or enterprise integration developer? At the most basic level, XML is simply a "meta-language with which one can define an actual markup language, such as that describing a catalog of automobile parts that are sold on a B2B exchange. But such a definition understates the potential of XML just as badly as the statement "XML will let various platforms talk to each other" overstates it. "XML" provides not only this rather abstract metalanguage, but also a community of experts, tools, examples, and associated specifications that provide a substantial percentage of the infrastructure that underlies Web-based applications and B2B integration efforts.

For example, compare and contrast a traditional EDI project and an XML B2B project. Both must begin with some standards body or coordination group meeting to thrash out the details of the data format and the semantics of the terms exchanged in that format; XML only provides the basic underpinnings of the format (the tag syntax), and almost nothing in the way of semantics. But once the format is specified, the two projects will proceed quite differently. Most of the underpinnings and deliverables of the traditional project must be custom-built, for example, a parser that turns the agreed-upon text format into an internal data representation that software can manipulate. Likewise, there will be few tools, tutorials, or outside experts available to assist with the custom-built components.

Both projects must still implement the specific functionality that they set out to deliver, of course. But with XML, this represents the vast majority of the work that must be done, whereas with the traditional project, it is just one of the many tasks that must be performed.

In short, XML provides, and has always been intended to provide, the underpinnings of a B2B, enterprise integration, Web portal, or other application. But it will never provide a "shrink wrapped" solution to all business problems. Its major advantage lies in the ability to buy rather than build most of the necessary infrastructure components.

A recurring theme in the XML community is the "80:20 rule." This is the goal of building 80 percent of the functionality of a solution with 20 percent of the effort. XML has proven to be very successful when measured against this standard, and this is all it has ever set out to accomplish.