By 2005 XML and its derivatives will be fundamentally redefining the process and technology by which literally every business transaction is conducted. All major software and hardware players in the market are claiming to support XML. But do you (or your colleagues) need to learn it? Will your business survive if you don't?

Jeffrey Mann, vice president of Meta Group (www.metagroup.com), predicts that by 2002 90% of B2B e-commerce will take place using XML. Most software companies agree that there's no future without XML. Most managers agree that if you're investing in a software application to support your business and you need to choose between one that supports XML and one that doesn't, the one that supports it makes more sense. This is probably true, but ask yourself why this is so. If you don't know the answer, you might find yourself investing in bad technology. And the best way to protect yourself is to educate yourself, although with such a wide range of choices it can be difficult to know where to start. Should you attend a half-day seminar? A one-day course? On site? Off site? How can you be sure that educators know what they're talking about and aren't simply disguising a sales pitch?

It's important to choose the right flavor of information when signing up for a course. Understanding what XML can do for you means understanding the technical reasons for using it on the one hand and learning about the solutions that exist because of it on the other. As with any new technology, there are pitfalls. For example, XML lets you create and extend application-specific languages that better describe your business data, but an antiques dealer will attach a different meaning to the word table than a database administrator.

Does this matter? Not in an application-specific language that's never used outside the scope of that application, but it matters when the antique dealer needs to exchange data with the database administrator.

Determining a Common Ground
There is a tendency to assume that if business partners use the same words in their applications, everybody can point their machines at each other and conduct business over the Internet. True, XML is an enabling technology that can help organizations achieve a high level of interaction, but in reality the chances of your proprietary system understanding somebody else's are so small that fortunes have been made in the past 20 years or so providing solutions. Few such solutions are repeatable, and many exacerbate the proliferation of nonstandard technology. And fortunes are still being made. Remember that the software developer's conceptual model of the world is unique and usually subjective to the scope of the employer's business. Using XML to "speak the same language" is one of the snakes in the grass that can waste more project time than any other factor if handled incorrectly.

Agreements between organizations about languages are obviously a good thing if they allow more business to be conducted with greater efficiency. What we're seeing in B2B e-commerce is that XML is giving organizations the tools with which to define common interfaces regardless of the deployment platform or underlying (and usually concealed) business model. Transforming between different XML vocabularies is fairly straightforward, and making one flavor of XML suitable for multiple uses is one of the strengths of the language. However, the importance of good design can't be overstated. The strength and versatility of a custom language has nothing to do with the fact that it's been written according to the rules of XML and everything to do with the intelligence of the software developer who designed it in the first place. If the budget holder and decision makers on a project aren't familiar with XML, and need to make a decision that requires a modicum of familiarity with the subject, one of the first steps they should take is to arm themselves with the faculties that allow them to judge the intelligence of developers.

XML has become such an emotive word in the vocabulary of hype that it has won the reputation of being a panacea for all ills. The tip of the iceberg is summarized daily by experts around the world. For example, in the words of Laura Walker, executive director of the Organization for the Advancement of Structured Information Standards (OASIS), "XML makes Internet-enabled business possible. Without XML, Internet-enabled business is impossible." True, XML is already the only acceptable way to conduct Internet-enabled business in health care, finance, the pharmaceutical industry, telecommunications, indeed almost any sphere of automated operations. Unfortunately, the extent of agreement that has to happen before organizations can converse with each other over the Internet is the hidden part of the iceberg that makes Internet-enabled business a challenge, XML or no XML. It's rarely a simple case of handshaking.

In many cases manufacturers who claim that their software supports XML mean that their software can generate XML when needed but processes everything else in a proprietary (that is, closed, non-XML) format. Is this bad? Perhaps not. But if you have a software budget to spend you need to be able to judge one way or another. Another consideration when attempting to understand an XML-based solution is to assess the quality. "Supporting XML" is not usually qualified with an adverb. Software that transforms an invoice into a recipe using XML is probably supporting XML badly. This may sound trite, but it's relatively easy to do and leads us to another of the great pitfalls with XML, which is the implicit suggestion that powerful solutions can be achieved quickly. It's true that XML provides powerful data processing and manipulation opportunities, but no XML-based data processing happens automatically. Expensive programmers and information designers make it happen. There's no automatic conversion or seamless delivery. Expensive XML engineers convert and seamlessly deliver. And incompetent engineers might create an expensive and illogical nightmare.

The world has often witnessed the guile of new technologies. The technical advance of a new technology is usually sorely needed. This is certainly the case with XML, but it comes with a price. Often, the initial cost of implementing new technology is absorbed by unsuccessful attempts to implement it properly in the first place. When the world was first exposed to the power of desktop publishing (DTP), for example, the phenomenal growth of the DTP tools market surprised everybody, not least the software industry. Users embraced the technology with open arms, and a new age of user-styled documents was born.

Much of this has carried through to the Internet, where home-grown Web sites are so easy to build, thanks largely to a wide range of powerful tools that handle the styling and code generation on the user's behalf. However, as any graphic designer will testify, DTP made it possible for users to create ugly documents very powerfully and quickly. Web site construction tools allow users to create ugly and unusable sites equally powerfully and quickly. The analogy with XML bears some comparison. The market for XML tools, products, and services grew from $44 million in 1998 to $310 million in 1999 and is forecast to reach $1.8 billion for 2000, an average growth rate of 539%.

The Hunt for Knowledge
XML is taking the world by storm. But the flip side to this massive growth is that XML provides great potential for abuse. The message here is that if you're going to adopt XML, be sure to do it properly from the outset. If need be, educate yourself! Most XML tools are in their infancy, and professional expertise is incredibly scarce. To quote from the hype, XML and Java may "empower the enterprise to forge new electronic partnerships that leverage the availability and ubiquity of the Internet to exchange and share data" (Simon Nicholson, senior marketing strategist, Sun Microsystems), but you still need to be both a Java expert and an XML expert before you can empower anything.

How do organizations bridge the knowledge gap? Information designers and Internet programmers can't learn too much XML. Managers and decision makers in organizations that rely on income from the Internet-based B2B sector can probably avoid learning how to create valid XML but need to learn what XML can do for their organizations. Adopting XML-based technology might mean retooling: database systems, authoring tools, office automation, and so on. The world is on a steep learning curve. There are books on XML (two or three new ones are published every week), but without some practical hands-on experience in a related technology such as SGML (HTML isn't enough), they'll be hard going. Tutorials are available for download on the Internet, but they won't tell you anything about strategic architectures and clever investments.

So what are the options? The range and depth of information that somebody needs to assimilate before he or she can answer the questions in this article and understand the overall picture require a different approach. XML is so important to our future that it's worth going back to school for, but beware.

Companies selling XML courses are springing out of the ground like toadstools in a rain forest. The quality of information provided is usually directly proportional to their length and inversely proportional to their commercial content. The experience of the instructor is a crucial factor in the equation.

So, where can you find unbiased, in-depth XML education? CSW Informatics Ltd. (www.csw.co.uk) came up with a formula that provides an interesting balance and looks set to become a new standard: XML Summer School at the University of Oxford (see Figure 1).

CSW held the inaugural event in the summer of 2000 at St. Edmund Hall in the heart of the historic city. Five days of classes were spread over Introduction, Advanced, and Practical "tracks." Students were able to combine sessions from all three tracks and thus tailor the classes to their ideal learning experience. The instructors included such leading figures as Robin Cover, managing editor of "The XML Cover Pages," Steve DeRose, chief scientist of Brown University's Scholarly Technology Group, Bob DuCharme, author of XML: The Annotated Specification (Prentice Hall), Peter Flynn of University College Cork, Ireland, and Lauren Wood, director of product technology at SoftQuad Software, Inc. All instructors are teachers rather than representatives of commercial organizations trying to sell a solution, and all take an ongoing, proactive role with W3C in defining the specifications of the XML standards themselves - passing on the benefits of their frontline experience to the students in their classes (see Figure 2).

Judging by the enthusiastic reactions of the students (nothing scored less than "good" on their appraisal forms - an exceptional result in technical education), the formula of the summer school is a welcome addition to the course offerings available to professionals. An interesting conclusion voiced by many is that the atmosphere of a few days spent in an Oxford college is conducive to real learning. Students slipped quickly out of their corporate identities to compare notes, ask difficult questions, provide real-life commercial problems that need to be solved, talk about their experiences with products and companies, and point each other in good directions for further learning. The instructors joined in the extracurricular activities and willingly answered everybody's questions, whatever the time, place, or relevance. If you need to learn XML quickly and thoroughly in a nonpartisan environment, you could hardly find a better way to do it.