High Hopes for the Universal Business Language

Those swimming in the acronym soup of industry XML specifications would be forgiven for being underwhelmed at the news of another XML language. This time, however, it's different for two reasons. First, UBL aims to clear up the current state of confusion, rather than add to it. Second, UBL's being spearheaded by Jon Bosak, who championed the development of XML 1.0 at the W3C.

We interviewed Jon Bosak about the new UBL activity, its relationship to ebXML, and its status with regard to intellectual property concerns.

Edd Dumbill: What were the reasons that led to the formation of the UBL effort?

Jon Bosak: Two things, basically.

First, the current multiplicity of XML business schemas (cXML, xCBL, RosettaNet, OAGIS, etc.) is causing a lot of headaches for systems integrators and IT managers. This situation is great for companies that sell professional services and transformation software, because it creates a demand for adaptors that can translate between these different formats, but it's a real pain for everyone else, and technically it's completely unnecessary. There are good reasons why a purchase order designed for the auto industry in Detroit won't work "as is" for the shoe industry in Brazil, but there's no good reason at all why a shoe wholesaler has to buy extra software to enable him to do business with two different Brazilian shoe manufacturers using different purchase order formats to do exactly the same thing. Businesses operating in the same business context should be able to use the same forms of data representation.

The second reason for UBL is to jumpstart a worldwide transition to electronic commerce from traditional business processes. Most of the emphasis so far has been on how to enable big multinationals to do business with each other, while relatively little attention has been paid to how we enable small companies to compete in the same virtual business environment. But most of the world's business is, in fact, done by small companies. I want to enable a five-person manufacturer of fabrics in Pakistan to bid on supplying a hundred units out of a purchase request for a million seat covers from General Motors. Seeing both parties to this transaction benefit equally is for me what this is all about.

I think that a lot of technical people overlook the fact that we already have a system of global commerce that's taken us over four thousand years to establish. I think we have to adopt an incremental approach if we want to be successful in changing something like this. Our objective shouldn't be to replace the existing system with something completely different; our objective should be to make that system more efficient by incrementally automating the parts of it that can easily be automated. Standardizing XML versions of basic business documents is probably the easiest and quickest way to do this -- and it's probably the only way that allows small businesses to get on board without requiring them to make impossibly expensive investments in completely new technology or requiring them to entrust their entire business to some big monopolistic software vendor.

ED: What does UBL intend to build?

JB: UBL will create a "Universal Business Language" that will be a synthesis of existing XML business document libraries. We're going to begin with xCBL 3.0 -- because it's already widely deployed and because it's freely available without any legal hassles -- and then we're going to evolve that into UBL by modifying xCBL in order to bring it into line with the other widely used XML business languages and with EDI and the Core Components data dictionary work done in the ebXML initiative.

The result of this will be a standard set of XML business document schemas that anyone, anywhere can download and use without having to pay for the privilege and without running into any ownership problems.

ED: Does UBL mean that ebXML has failed?

JB: No, not at all. The ebXML initiative was focused on business process modeling, core component definition, and the creation of several critical infrastructure specifications. It never had the creation of particular XML business schemas as a deliverable; in fact, ebXML is neutral with regard to particular XML syntaxes.

At the end of its first phase in May 2001, ebXML delivered three basic components of a first-generation infrastructure for XML-based electronic commerce: a specification for XML messaging, a specification for trading partner agreements, and a specification for registry/repositories. All three of these specifications are now being maintained by OASIS technical committees. These specifications were designed in a way that allows businesses to use any one of them separately or all three together. But it's my belief that adding two more pieces will make global electronic commerce really take off. Those two pieces are a standard set of XML business documents and a standard choreography for exchanging those documents. UBL is intended to provide the standard documents.

ED: What timescale is UBL being conducted on?

JB: UBL has two big tasks to accomplish. The first task is the alignment of the vocabulary inherited from xCBL with all of the other inputs to this process -- EDI, ebXML, cXML, RosettaNet, OAGIS, and so on. The second task is the implementation of a methodology for context-driven component assembly so that, for example, a purchase order to be used in a particular business context can be assembled from the generic pieces in the core library.

Share your views on the UBL effort in our forum.

Post your comments

If these two tasks are carried out serially, then our best guess right now is that each of them should take about a year to complete. If it turns out to be possible to carry them out in parallel, then our best guess is that the whole thing will take a year or two.

ED: I notice Microsoft is not in the initial list of committee members. Is it your desire to get them on-board? Does it matter?

JB: It is absolutely our desire to get Microsoft involved in UBL. They have been observing this initiative, and I hope that they will eventually decide to join us.

ED: How will you measure the success of UBL?

JB: By its rate of adoption among small and medium-size businesses.

ED: Do you expect TC members to implement and test UBL in parallel with its development?

JB: Yes. In fact, this is one of the reasons for starting with an existing syntax; the vendors and users of systems based on xCBL are going to have to start testing to ensure that those systems continue to work as we evolve the language.

ED: What's the UBL TC's position with regard to patented technology?

JB: The current OASIS IPR policy can be found on the OASIS site; basically, it's identical to the IETF IPR policy. As the charter of the UBL TC makes clear, the people involved in UBL are contributing their work with the understanding that the result will be "freely available to everyone without licensing or other fees."

My possibly naive belief is that things like purchase orders and invoices have been around long enough that the issue of software patents simply doesn't apply them. This is actually one of the reasons for concentrating on documents rather than on business processes. A document like an invoice has to work in a lot of specific business processes, but it doesn't express or embody any particular process out of the infinite number it can work within.

The big problem with business forms would be copyrights rather than patents. This is why we decided to start with a specification that was already free of copyright attachments. By starting with documents from which we have clear legal right to make a derivative work, and creating that work in an organization dedicated to making its specifications free to everyone, I'm hopeful that we can avoid intellectual property complications altogether.