Let me make my opinion perfectly clear. I've been working on standardizing XML-based languages for electronic commerce for five years . After enduring countless conference calls, endless committee meetings, a few major initiatives that have yet to yield any fruit, and a few death marches, I've come to the conclusion that there isn't going to be a single standard XML-based language for common business documents. (Note that I'm using the singular "language" in the broad sense, as opposed to the more precise but technically focused use of the "language" of a specific type of document.)
Why am I so pessimistic? There are several reasons, but let me mention just a few of the most important. People categorize and name things in myriad ways. Even when they may basically agree with each other, there are inherent difficulties in communicating complex, abstract concepts. Achieving consensus is often daunting, and difficulty increases proportionally to the size of the group that needs to achieve consensus. As if those factors weren't sufficient, there are already several different XML business languages in use. Once people have started using something it is hard for them to change. Given these factors, I think it unlikely that there will be a single XML-based business language for even the English-speaking world. Beyond that, consider that businesses in France, Germany, Russia, or Japan might want to receive their orders and invoices using XML documents with Elements and Attributes using names from their own spoken languages. Finally, even in the unlikely event that such a single standard language could be developed, it is quite another matter for every application developer to provide native support for it. I would truly be pleased if history proves that I'm overly pessimistic, but the passage from Genesis seems particularly appropriate. It is an interesting observation that the UN/EDIFACT EDI standard, with its relative lack of names in any particular language, has proven to be useful to people using a wide variety of spoken languages. There is a somewhat ironic parallel between the all-powerful W3C sending forth XML and the God of Genesis confusing people's speech.
While we must acknowledge this bleak situation, all is not lost. It may not have given us salvation, but the W3C has at least given us a palliative . It may even be good enough for a wide range of situations. This is interesting because, if we can take the W3C's statements at face value, it is not necessarily what it originally set out to do. The XSL Transformations Recommendation, Version 1.0, contains the following little caveat right at the beginning of the document.
This is a situation in which the familiar law of unintended consequences comes into play. It is often the case that when a clever tool or technology is developed, people put it to uses that the originators never intended or anticipated. While this statement says that the W3C didn't intend to develop a completely general purpose XML transformation language, I wonder if the Consortium quite anticipated or understood the babble of overlapping dialects that would emerge when it created XML. I'm also not convinced that the members quite understood some of the ways in which people will actually use XML documents. There is a legitimate need for a general purpose XML transformation language, and I don't know of a better candidate than XSLT.
I intend in this chapter not only to show how XSLT can help deal with the babble but also to prove that it is a very appropriate tool for many environments. XSLT processors can perform a wide variety of logical document conversion tasks . They can even do things that many of the mappers packaged with EDI management systems can't do. XSLT processors may not at present be the most efficient means of converting documents, but when combined with conversion utilities such as those developed in this book, they can be a key part of a low-cost, portable, and platform-independent electronic commerce or EAI solution. And with the emergence of XSLT compilers and hardware accelerators, performance limitations may likely become less of an issue in the future.