OASIS is involved in quite a range of XML activities. In my last column I discussed its increasing role in helping to standardize XML applications and talked about what's being done with XML.org. In this column I'll introduce you to the Electronic Business XML Initiative (ebXML), OASIS's joint initiative with the United Nations/CEFACT group.

Let's begin with some background related to e-commerce. First, it's not a new idea ­ companies have been buying and selling goods electronically for 20 or 30 years. They weren't using the Internet or XML back then, of course, but rather EDI ­ electronic data interchange. This technology, usually associated with rigid, predefined message sets and value-added networks (VANs), is still in wide use today.

The VANs are private networks that guarantee message delivery and provide a certain level of security. For cross-industry commerce the two major dialects of EDI messages are ASC X12 and EDIFACT. X12 began life as an essentially North American standard while EDIFACT covered much, though not all, of the rest of the world. The group, now called UN/ CEFACT, developed and continues to maintain EDIFACT. Since cross-border mergers and acquisitions are not uncommon business activities, some companies use both message format specifications for dealing with trading partners.

EDI is big business ­ especially for big businesses. It's been estimated that 98% of the Fortune 1,000 use some form of EDI and that the overall use of EDI is growing. The cost savings in terms of time, money and effectiveness are significant, and it's a reliable way to transmit electronic messages up and down your supply chain. EDI is also a good business for companies that provide EDI programming, support and VAN services. (Here's my regular disclaimer: I work for IBM, one of the leading companies providing EDI services; the opinions expressed in this column are my own.) So what could possibly be wrong, given the apparent widespread acceptance of EDI and the evident business advantages for everyone involved?

While EDI use ­ according to Gartner ­ is indeed growing overall, the rate of growth is slowing. Adoption remains strong in the big companies, but outside the Fortune 1,000 the implementation rate is estimated to be as low as 5%. That's a big difference, especially when you think about the players in a typical supply chain. At some point in the chain the programming, maintenance and VAN costs get too large for small- and medium-sized enterprises (SMEs). So what we see are electronic messages moving back and forth among the big players, and faxes, phone calls and paper used among the smaller ones. I'll leave it to you to think about the reliability aspects of receiving a faxed purchase order and then typing the relevant portions into your in-house order-tracking system. To make matters worse, that purchase order was probably printed from a computer before it was faxed. All this clearly adds cost and time to the process of buying and selling goods.

Ray Walker, chair of the UN/CEFACT group, adds another important perspective when he reminds us how easily developing countries, as well as SMEs, can be left out of the electronic B2B (business-to-business) world. If the cost of the infrastructure is too high, the number of potential partners with whom you might do business electronically is limited accordingly.

So it's not altogether surprising that people have turned to the ubiquitous Internet and its related technologies to help reduce the expense of connecting to as many trading partners as possible. One of those related technologies is XML.

Helping Move EDI Forward
Traditional EDI messages are broken into sections, subsections and fields, with separators between them. The message format is rigid in the sense that information must be placed in certain locations or it is ignored or rejected. The data isn't self-describing, but it isn't particularly verbose either, except that parts of general-purpose messages may be left empty in specific scenarios. The skills and tools related to working with EDI messages are specialized and therefore expensive. This is a great place to apply XML for message formats. Companies like XML Solutions (www.xmlsolutions.com) are doing just this, and organizations such as the loosely knit XML/EDI group have studied how XML can best be used in moving EDI forward and making it more pervasive.

The value of XML hasn't been lost on EDI users in vertical industries. Health Level Seven (www.hl7.org) has been working on an XML representation for version 3 of its specifications. HL7 and OASIS recently exchanged reciprocal memberships so that the XML technical work of each can be more widely and effectively shared throughout the industry.

Note that moving EDI to an XML/Internet base is not the only XML activity in e-commerce today. Companies such as Ariba and Commerce One have used XML and the Internet to create procurement solutions. While auctions, marketplaces and exchanges are all commerce models that are rapidly becoming important and profitable, EDI wasn't designed to support these kinds of transactions.

If you look at all the cross-industry and vertical industry messaging solutions, there's a tremendous amount of redundancy and repetition of standards development around infrastructure. Take the message envelope that surrounds the actual domain-specific payload of a business message (for example, a purchase order, a stock transaction, a lab test request or a plane reservation confirmation). This envelope probably contains information concerning who originated and who is to receive the message. Beyond this, the information in the message envelope can vary quite a bit in content and format.

Microsoft's BizTalk, Open Buying on the Internet (OBI), RosettaNet and the EDI message specifications all use different message envelope representations. B2B software that operates across enterprises must have components to read and parse each of these formats, thereby adding to the base cost of the applications. When still another message envelope format is developed, maintenance and upgrade costs will increase accordingly.

Defining Universal Specifications
It's unrealistic to think that a single vendor or a narrowly scoped industry standards consortium can define a universal message envelope format that then gets adopted across multiple industries. But perhaps a broad-based consortium of companies, trade organizations and industry groups has the wherewithal to define specifications such as this and to actually get them widely implemented.

It's the hope of OASIS and the United Nations/CEFACT group that ebXML is just such an initiative. The ebXML effort was announced in September 1999. Klaus-Dieter Naujok of Harbinger Corporation and the UN/CEFACT group is the chair and I represent OASIS as the vice chair. The mission of the initiative is "to provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties." The official Web site is at www.ebxml.org.

Our first meeting was held in San Jose, California, in November and was attended by more than 120 people representing more than 50 organizations from around the world. It was largely a "show and tell" meeting during which the EDI people and XML e-commerce people explained to each other what they'd been doing and what they hoped ebXML might accomplish.

As you might expect, the meeting wasn't without its share of politics. But I'm happy to report that the group came together to create eight project teams whose purpose is to define and implement the work of the initiative over the planned 12- to 18-month time frame. The project teams are shown in Table 1.

Each project team has its own page on the ebXML Web site describing its mission, goals and progress. The technical architecture team encompasses the "big picture" of our technical work. Here's how it describes core components, for example: "Core components are elements of the component library that are common to multiple business domains. These core components are used within domain-specific components and are also specialized for domain-specific requirements."

Although these teams had already done some work in the two months following the first meeting, things got going for real at the second meeting in Orlando at the end of January 2000, which took the form of three days of team meetings surrounded by two half-day plenaries. The team meetings were exhaustive analyses of prior art in each area and strategy sessions for how to move ahead. Let me emphasize that the ebXML effort isn't trying to create all the technology it needs from scratch but rather to borrow the best existing technology, which will then be combined with new work to create a cohesive infrastructure for e-business.

In order to be relevant to the development of e-business, the ebXML effort needs to produce its specifications in a timely manner and must make drafts available every few months. The first draft specifications will be available after the Brussels meeting in May. We're actively soliciting the help of organizations such as the IETF to assist in the rapid development of the ebXML framework. Participation is open to everyone and you can register yourself for project team participation at the Web site.

In my next column I'll discuss a complementary technology that's being standardized within OASIS/XML.org called Trading Partner Agreement Markup Language. You can start learning about it by reading the initial submission from IBM at www.xml.org.