UBL: The Data Standard for Commerce
As its domain-specific exchange format for data and documents, Lichen adopts the Universal Business Language library (UBL; ISO/IEC 19845).
UBL is a royalty-free library that harbors formal naming, definition and structuring of data for commerce as well as a business document taxonomy to support various functions of supply-chain trading partners such as sourcing, ordering, fulfilling, billing, transportation and payment arrangements.
For more than a decade, UBL has been a free/libre/open standard under the Organization for the Advancement of Structured Information Standards (OASIS). The OASIS technical committee process supports participants in an industry or economic sector in creating common information and document specifications. The process is explained in this essay by the Chair of the Technical Committee for the UBL business document interchange specification. In 2015 UBL also gained accreditation with the International Organization for Standardization (ISO) and the International Electrotechnical Commission as ISO/IEC 19845.
Data and Document Types for Any Aspect of Commerce
A common first impression of UBL is that it is voluminous and complex. But this is only because e-commerce needs to be:
(a) computationally well-structured;
(b) un-restrictive of market freedoms and preferences; and
(c) comprehensive, so as to support a diversity of evolving laws across all jurisdictions.
That’s a tall order! But UBL has been evolving for more than a decade to accommodate the full diversity of e-commerce contexts and functions. Today it encompasses 65 different e-commmerce document schemas, comprised of 229 re-usable components and 4,112 information items, and it includes a formal methodology for further customization. The forthcoming UBL 2.2 will add another 16 document types and 500 information items.
Fortunately, the UBL community embraces the 80/20 principle. This means, notionally, that 80% of the sourcing, ordering, fulfilling, billing and payment set-up requirements in any particular e-commerce system can typically be met with just 20% of the UBL standard. A business or a solution developer would customarily find that about 20% of the specification will cover about 80% of their required data fields.
UBL is Adaptable
The authors of UBL assume that implementers will want to customize UBL when designing any particular commerce solution. Consequently, they make the customization methodology an integral part of the standard. Customization can involve restriction (i.e. cherry-picking the parts of the UBL standard that you want) and/or extension (grafting on a new branch).
When an implementer uses the mandatory parts of UBL, along with just a few optional elements needed in a given context, such an implementation is referred to as “conformant” with the standard. The implementer’s subset of the UBL standard will be fully validated as an implementation of UBL.
Since the standard is so comprehensive, it is rare for an extension to be necessary. Nevertheless any implementer can define an extension to UBL without degrading interoperability with other UBL-conformant systems. When properly done, extensions do not disturb UBL-schema validity, so the resulting document would remain UBL conformant. Any extension data types, of course, will interoperate only with other systems that employ those same extensions. But extension packages can be distributed independently to any system then requires interoperability.
If an extension is addressing a common requirement, it is advantageous to keep it aligned to UBL’s recommended naming conventions and design rules. If the UBL Technical Committee determines that these would help towards meeting widely experienced business needs, they may choose to incorporate them into future versions of the standard. Complying with the naming conventions and design rules also facilitates issue response, and on-boarding of technical personnel.
