What do you hope UBL would accomplish?
It's a complicated situation with businesses trying to move from paper commerce to electronic commerce. We've had EDI (Electronic Data Interchange) for 20 years, and three-quarters of all electronic commerce is done via EDI. The problem with EDI is that it's expensive, and that limits business-to-business e-commerce to multinational corporations and their dealings with each other.
UBL deals with a range of problems facing small and medium-sized businesses, like access to e-commerce, and how to expand the relationships of multinationals to include small companies. This is a separate problem as companies are turning their attention to how to make the transition from paper and fax to an electronic commerce mode to make best use of free Internet.
One barrier has been the lack of a standard set of XML formats for common business documents. UBL is based on the premise if you provide standard XML versions of business documents, you will solve a lot of these problems.
UBL 1.0 defines eight standard documents anyone would recognize (order, order response, order response simple, order change, order cancellation, dispatch advice, receipt advice, and invoice). It's been done in a way that maps exactly to the paper document and to the EDI standard formats. It's a bridge to e-commerce from the high and low ends.
The implications are revolutionary. The tasks are straightforward, taking existing EDI and paper processes and putting together in XML formats. It's not hard to understand. The impact of the existence of these things could be profound. It could nucleate a whole set of developments. You've compared the impact UBL could have to the arrival of HTML. Could you explain?
The flexibility of XML is there to enable the creation of a limited number of standard markups that function in specific domains. When you standardize markups, magic happens. Software gets cheaper. Training gets easier. All kinds things coalesce.
My visionary assertion is that HTML is a really good example of what happens. When HTML appeared, we were all using elaborate markup languages. With the appearance of HTML -- many felt it was too simple to work -- the advantages of a single markup more than made up for its limitations. A single thing to learn was more important than all of limitations. Attempting something simple with UBL like the order-to-invoice procurement scenario, we're stepping into a space where there's no available horizontal markup for this purpose. My hunch is that we will see some kind of impact analogous to HTML. Can you describe the process the technical committee took to arrive at UBL?
The key thing to understand about UBL was the controversial decision made at beginning of the process. The politically correct thing to do would been to say review all work done in this space [and start from scratch]. We didn't. We wanted to start with a successful commercial XML language (xCBL, a mature XML specification created by Commerce One and SAP AG), and still create a derivative work to remain royalty free. It also had to have library architecture.
For example, in X12 [an EDI standard] and Rosetta Net, you'll find some of the same document types we defined. But under the hood, there's a big difference: for example, the purchase order is developed separate from the invoice and shipping notices. If you're trying to write code, you're limited because of the way you did the address in purchase order that's not the same as on the invoice. Twenty years of experience taught us that things are shared between documents, and that we should build a library and standardize components. Then build library from those components. One candidate was xCBL.
XCBL was created by Vio Systems in 1998. CommerceOne then bought it and released 2.0. SAP partnered with CommerceOne 3.0, and put in an immense amount of work to interoperate with customers and SAP applications. We started with UBL with xCBL three years ago. Now we're at 6 years of development. Still in some minds, it was a controversial thing to do, but in retrospect, it was the right thing to do. We have a three-year lead on anyone else.
The documents we picked are the ones that are most basic to simple procurement -- the most basic kind of electronic transaction.
If look at EDI, you'll find 40 or 50 documents types, a whole world of possibilities including a whole range of things before and after payment scenario. We are not going there yet. That lies in future.
When we started, there was a limited set things we wanted to do. I got a good look on Rosetta Net and was astonished to find how many users implement only a couple of those documents. OK, this may be small set of possible set, but interesting to see what percentage of actual use we've nailed. But you've left room to standardize more business documents?
Our future plans for UBL are complicated by the fact that we long time in negotiations with UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and whether it wants to adopt UBL. A lot of UBL's future is going to be determined by them.
In the coming year, we will develop UBL 1.1. We got a lot of feedback for localization -- and not just translating. For example, in Japanese commercial law, every invoice has to have field for an inspection date; that did not come up in other requirements. In 1.1, we will have to define a field for inspection date in invoices.
We also expect feedback with respect to how we've defined these business terms. We need to introduce particular distinctions or definitions. Nothing will change the schemas. Documents validated against 1.0, should validate against 1.1. You mentioned UN/CEFACT, one of the earlier ebXML collaborators. Can you explain the relationship between ebXML and UBL?
The UBL technical committee started when some ebXML participants wanted to define schemas for XML payload that is exchanged; something that's necessary in EDI.
As a result, UBL works perfectly with a structure like ebXML. But there's nothing in UBL that says anything about ebXML. It's just a data format. EbXML does a nice job abstracting business processes into a separate set of specs. Although we work with ebXML, it also should work with anything else that works with message-based B2B communication.