This article is more than 1 year old
XML Tower of Babel - bring on UBL
XML is taking over the world for all sorts of good reasons. But just as we thought that it would solve all our problems and let us build a tower up to the gods, babble intervenes.
XML has allowed messages to be passed from one system to another in such a way that they can be parsed, dissected, queried and rebuilt, but it only deals with the syntax and not the semantics. To take a simple example, different messages using different schemas could have tags like: zip, zipcode, zip_code, post-code, post_code, postal_code, or PostalZone, all of which in a generic sense relate to the same type of data. So a message from one schema has to be transformed into another schema before it can be processed.
This causes considerable redundant processing as well as adding significant opportunities for errors, potential security exposures and a need for additional modelling and testing. It also reduces the opportunity for reuse and discrete services. For example, it should be possible to develop a service that can be handed any XML stream and it will add the insurance group for the PostalZone and pass the message back; this would be much easier if the tag was always the same.
Individual element names are one level of the problem and the next level of problem is messages for typical transactions such as an invoice. Again the advantage of a single agreed format would be immense.
Well, OASIS, the e-business standards organisation, looks as if it has solved this problem with the publication of its Committee draft of the Universal Business Language (UBL) 1.0 last month. This is a major piece of work which is freely available and I believe should be the standard by which all new XML schemas and messages are built. It provides for extensions and is obviously not yet universal in its coverage. It does however cover many of the basic concepts and elements needed as its documents and component library are designed to support a typical order-to-invoice procurement cycle. It includes the following document types: Order, Order Response Simple, Order Response (detailed), Order Change, Order Cancellation, Despatch Advice, Receipt Advice and Invoice.
My initial review of the standard shows a great deal of thought and understanding from the members of the committee. Given its size it is remarkably easy to navigate around and find bits of interest. Ever since my early data modelling experience, with a pre-release version of IMS/DB, deciding how best to deal with addresses has been a major issue. So I looked at this area in particular and it does seem to work well and give the flexibility needed (this is partly due to the greater flexibility of XML over IMS) and I can easily see this becoming the standard. One small criticism is that the definitions are somewhat terse and it is probable that over time they will need to be expanded to ensure real commonality of semantics.
In short, an excellent version one with plenty of promise of more to come.
For the detail go here: you still have time to comment.