The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: April 30, 2004.
News: Cover StoriesPrevious News ItemNext News Item

Universal Business Language (UBL) 1.0 Approved as an OASIS Committee Draft.

Contents

Summary

Approval of the Universal Business Language (UBL) Version 1.0 as an OASIS Committee Draft represents a major publication milestone in the arena of e-business message exchange standards development.

Freely available to everyone without legal encumbrance or licensing fees, UBL "defines a generic XML interchange format for business documents that can be extended to meet the requirements of particular industries. The specification is designed to provide a universally understood and recognized commercial syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes."

"UBL 1.0 represents six years of continuous development in the creation of a standard XML business syntax, the last two years of which have taken place in the OASIS Universal Business Language Technical Committee. The UBL Committee Draft incorporates more than a year of public review, and the final result is now ready for implementation in commercial and open-source software efforts."

The UBL v1.0 Committee Draft release is distributed for public review as a ZIP archive with some 244 files, containing prose documentation, normative XML Schemas, UML diagrams, spreadsheet models, formatting specifications, sample instances, and other components. A UBL ASN.1 specification provides an alternative schema definition for UBL documents in accordance with ITU-T X.680-X.693.

The UBL v1.0 release provides a library of XML schemas for reusable data components, small set of XML schemas for common business documents useful in a generic order-to-invoice trading context, and support for the customization of UBL in specific trading relationships.

In addition to schemas defining the eight basic document types that support the generic UBL 1.0 order-to-invoice process, the release contains modularized common XML schemas (reusable BIE schemas, reusable datatype schemas, a documentation metadata schema, and thirteen code list schemas). The code lists provide restricted sets of coded values which may populate particular UBL data fields, viz., code values for Acknowledgement Response, Allowance Charge Reason, Channel, Chip, Country Identification, Currency, Document Status, Latitude Direction, Line Status, Longitude Direction, Operator, Payment Means, and Substitution Status.

The UBL schemas are "modular, reusable, and extensible in XML-aware ways. Designed as an implementation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on a conceptual model of information components known as Business Information Entities (BIEs). These components are assembled into specific document models such as Order and Invoice. These document assembly models are then transformed in accordance with UBL Naming and Design Rules into W3C XSD schema syntax. This approach facilitates the creation of UBL-based document types beyond those specified in the version 1.0 release."

A UBL overview document describes the basic order-to-invoice business process that the UBL document types are designed to support. This basic trading cycle model involves three parties: a Buyer of goods, a Seller of goods, and a Recipient of goods who may or may not be the Buyer. UBL document types defined to support this process include Order, Order Response Simple, Order Response Detailed, Order Change, Order Cancellation, Despatch Advice, Receipt Advice, and Invoice.

The UBL v1.0 Committee Draft makes normative reference to standards/specifications which define XML, W3C XML Schema (Structures, Datatypes), Abstract Syntax Notation One (ASN.1), Unified Modeling Language (UML), IETF RFC 2119 (Key Words for Use in RFCs to Indicate Requirement Levels), ISO 11179, and UN/CEFACT ebXML Core Components Technical Specification 2.01 (CCTS). The terms Object Class, Property Term, Representation Term, and Qualifier are used in the UBL v1.0 specification with the meanings given in ISO 11179 (viz., ISO/IEC 11179-1:1999 Information Technology — Specification and Standardization of Data Elements — Part 1: Framework for the Specification and Standardization of Data Elements).

Of UBL's Normative References, the specification most frequently cited is CCTS (UN/CEFACT ebXML Core Components Technical Specification Version 2.01). UBL appendix G.3.4 on "Core Component Harmonization" clarifies that UBL is indeed an implementation of CCTS, supporting "the concept of a common semantic library of business components [core components]... The UBL TC is working with the UN/CEFACT International Trade and Business Processes Working Group on Harmonization (TBG17), the group is responsible for consistency and harmonization of business process models and core components across business domains and sectors, contributing to a concise and well-defined glossary of business terms, business data semantic definitions, and structuring of data exchanges." The UBL terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC), Association Core Component (ASCC), Business Information Entity (BIE), Basic Business Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) are used in the specification with the meanings given in the ebXML Core Components Technical Specification.

Special Projects undertaken by members of the UBL Technical Committee in reaching the Committee Draft level include design, development, and QA projects for Business Modeling, XSD Schema Generation, XSD Schema Validation, XSD Rules Review, ASN.1 Generation, UML Generation, UN Layout Key Formatting, CCTS Alignment, and Quality Assurance.

The UBL effort within the OASIS UBL TC has been directed by Jon Bosak (TC Chair) and Mark Crawford (TC Vice Chair), together with leadership provided in the sixteen UBL Subcommittees, including: Library Content; Naming and Design Rules; Tools and Techniques; Implementation; Forms Presentation; Code List; Context Methodology; Context Drivers; Administration; Liaison; Marketing; Chairs.

Four subcommittees have been formed to promote international adoption of UBL deployment. According to the TC announcement, "OASIS UBL localization subcommittees have been formed to translate the UBL specification into Chinese, Japanese, Korean, and Spanish. When complete, this localization work will make UBL readily usable for more than two-thirds of the current global online population. The next UBL TC meeting, to be hosted by Hong Kong University 10-14 May 2004, will set the work schedule for UBL localization, continue to further refine the technical basis of UBL, and begin to develop a process for the creation of industry-specific UBL profiles."

The approved UBL v1.0 Committee Draft is being submitted to OASIS for public review in preparation for OASIS standardization. The UBL TC announcement of 2004-04-30 declares that UBL version 1.0 is now available for general use.

Bibliographic Information

Universal Business Language 1.0. Edited by Bill Meadows (Sun Microsystems) and Lisa Seaburg (Aeon LLC). Status: Approved OASIS Committee Draft. Produced by members of the OASIS Universal Business Language (UBL) Technical Committee under the direction of Jon Bosak (TC Chair, Sun Microsystems) and Mark Crawford (TC Vice Chair, Logistics Management Institute). Contributors include Members of the Technical Committee. Publication Date: 1-May-2004. Document identifier: 'cd-UBL-1.0'. Location: http://docs.oasis-open.org/ubl/cd-UBL-1.0/. Downloadable Package Location: http://docs.oasis-open.org/ubl/cd-UBL-1.0.zip.

The normative UBL schemas contained in the ZIP archive "are accompanied by a multitude of informative supporting materials, some of which are included in the version 1.0 CD package as informative appendices, and some of which are available from referenced sites."

Key documents included in the UBL v1.0 distribution, in addition to XML Schemas and UML diagrams:

UBL Version 1.0 Committee Draft Release Materials

Materials included in the release include:

  • UML class diagrams of the document components on which the schemas are based
  • UML class diagrams describing all the document assemblies
  • Spreadsheet models defining the document assemblies
  • Descriptions of two example implementations
  • Sample instances of each of the UBL documents used in those two implementations
  • Formatting specifications for rendering all of the documents in the example use cases
  • Formatting specifications for the United Nations Layout Keys corresponding to each of the UBL basic business document types
  • An ASN.1 specification to enable the transmission of UBL messages in binary form

UBL Document Types Supporting the Order-to-Invoice Cycle

In the main UBL v1.0 CD document, Section 5 ("UBL 1.0 Procurement Process") provides details of the order-to-invoice business process, including the "business rules and choreography of the generic procurement process and the role played by each of the UBL 1.0 document types in that process." Summary of the document business rules for each of the principal document type follows (adapted).

  • Order "The Order may specify allowance and charge instructions (e.g. freight, documentation, etc.) that identify the type of charge and who pays which charges. The Order can be placed 'on account' against a trading credit account held by the Seller, or against a credit/debit card account, or a direct debit agreement. The Order allows for an overall currency defining a default for all pricing and also a specific currency to be used for Invoicing. Within an Order, additional currencies can be specified both for individual item pricing and for any allowances or charges. Trade discount may be specified at the Order level. The Buyer may not know the trade discount, in which case it is not specified. This makes a detailed response from the Seller necessary... The Order may specify delivery terms and constraints that apply for the delivery location in relation to the following information that would normally not appear until the Despatch Advice..."

  • Order Response Simple "The Order Response Simple is the means by which the Seller confirms receipt of the Order from the Buyer, indicating either commitment to fulfill without change or that the Order has been rejected."

  • Order Response (detailed) "Proposed changes by the Seller are accomplished through the full Order Response document. The Order Response proposes to replace the original Order. It reflects the entire new state of an order transaction. It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that were not available to, or specified by, the Buyer at the time of ordering."

  • Order Change "The Buyer can change an established Order in two ways, subject to the legal contract or trading partner agreement: first, by sending an Order Change, or second, by sending an Order Cancellation followed by a new, complete replacement Order. An Order Change reflects the entire current state of an order transaction. Buyers can initiate a change to a previously accepted order for various reasons, such as changing ordered items, quantity, delivery date, ship-to address, etc. Suppliers can accept or reject the Order Change using either Order Response or Order Response Simple..."

  • Order Cancellation "At any point of the process, a Buyer can cancel an established order transaction using the Order Cancellation document. Legal contracts, trading partner agreements, and business rules will restrict at what point an Order Cancellation will be ignored (e.g. at the point of manufacture or delivery process initiation). Given the agreements and rules, an Order Cancellation may or may not be an automated business transaction. The terms and conditions of contract formation for business commitments will dictate which, if any, of these restrictions or guidelines will apply..."

  • Despatch Advice The following information may appear in the Despatch Advice: Transport and Consignment packaging. The Despatch Advice provides for two situations: (1) Organization of the delivery set of items by Transport Handling Unit(s) so that the Receiver can check the Transport Handling Unit and then contained items. Quantities of the same item on the same Order Line may be separated into different Transport Handling Units, and hence appear on separate Despatch Lines within a Transport Handling Unit. (2) Organization of the delivery set of items by Despatch Line, annotated by the Transport Handling Unit in which they are placed, to facilitate checking against the Order. For convenience, any Order Line split over multiple Transport Handling Units will result in a Despatch Line for each Transport Handling Unit they are contained in..."

  • Receipt Advice "The Receipt Advice is sent by the Receiver (Buyer) to the Seller to confirm receipt of items and is capable of reporting shortages or damaged items. The Receipt Advice provides for two situations. For ease of processing claimed receipt against claimed delivery, it must be organised in the same way as the corresponding Despatch Advice: (1) Indication of receipt by Transport Handling Unit(s) and contained Receipt Lines one-to-one with the Despatch Advice as detailed by the Seller party. (2) Indication of receipt by Receipt Lines annotated by Transport Handling Unit, one-to-one with the Despatch Advice as detailed by the Seller party. The Receipt Advice allows the Receiver to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason..."

  • Invoice "The Invoice is normally issued on the basis of one despatch event triggering one invoice. An Invoice may also be issued for pre-payment on a whole or partial basis. The possibilities are: (1) Prepayment invoice (payment expected); (2) Pro-forma invoice (pre advice, payment not expected); (3) Normal Invoice, on despatch for despatched items; (4) Invoice after return of ReceiptAdvice. The Invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the Order, Order Change, Order Response, Despatch Advice, or Receipt Advice that is not necessary when invoicing. If necessary, the Invoice refers to the Order, Despatch Advice or Receipt Advice by a Reference for those documents..."

UBL Methodology

The Informative Appendix B published in the UBL v1.0 overview document describes the UBL Methodology in terms of the UBL Development Approach, Component Model, Document Assembly Models, UBL Naming and Design Rules, Schema Generation, Implementation Model, and Customization Guidelines. This technology pioneered by the UBL TC in the use of normalized (spreadsheet-driven) representations for schema knowledge to generate UML diagrams and modularized (reusable, extensible) schemas is noteworthy in its own right — independent of the UBL application. A summary is provided here (adapted from the published text).

UBL Development Approach "While UBL does not mandate the use of a specific formal development method, the process that evolved during the development of UBL is documented so that implementers can understand the role of the various technical artifacts included in the v1.0 package... The initial UBL library of data components was based upon the xCBL 3.0 schema library, which was itself based on the UN/EDIFACT and ANSI X12 EDI component libraries. Upon review, it was felt necessary to create an abstracted conceptual model of the entities in a form that would better support an iterative development lifecycle. UBL uses two types of conceptual models, a single model for defining information components and a set of models for describing how these components are assembled into document definitions. The former is referred to as the document component model and is generally presented using UML class diagrams; the latter are referred to as the document assembly models and are generally presented using spreadsheets..."

Component Model "The UBL document component model describes the information components used in all of the documents defined by UBL 1.0. It is best viewed as a series of UML Class Diagrams. To facilitate comprehension of the UBL Document Component Model diagram, it has been decomposed into several packages. Each package represents a logical grouping of components and is described by its own UML class diagram, which displays both the attributes (Basic BIEs) and object classes (Aggregate BIEs) belonging to the components grouped in the package. The scope of each package is arbitrary and does not hold any significance beyond these diagrams. The complete set of packages for all the UBL components includes: Address Package, Contract Package, Delivery Package, Document Reference Package, Hazardous Item Package, Item Package, Party Package, Payment Package, Procurement Package, and Tax Package..."

Document Assembly Models "To define different types of documents, the components described in the previous section are assembled into hierarachical structures based on the requirements of the context — in this case the UBL 1.0 Procurement Process — and the metadata requirements of CCTS. Document assembly starts with the definition of each of the business documents comprising UBL 1.0 as an Aggregate BIE (object class) for the document type. All the other Aggregate BIEs (object classes) for the document type are derived by traversing the associations from this Aggregate BIE to form the required hierarchy. The roles chosen for each association between Aggregate BIEs become Association BIEs... The top level document assembly models for the eight business documents defined by UBL 1.0 are: Order assembly model, Order Response assembly model, Order Response Simple assembly model, Order Change assembly model, Order Cancellation assembly model, Despatch Advice assembly model, Receipt Advice assembly model, and Invoice assembly model... UBL uses spreadsheets to describe the assembly of components into specific types of documents. There is one spreadsheet assembly model for each document type..."

UBL Naming and Design Rules "The UBL XML Naming and Design Rules (NDR) checklist included in the package describes the rules used to determine UBL 1.0 XSD schema structures and element/attribute names." Attribute Declaration Rules, Attribute Naming Rules, Code List Rules, ComplexType Definition Rules, ComplexType Naming Rules, Documentation Rules, Element Declaration Rules, Element Naming Rules, General Naming Rules, General Type Definition Rules, General XML Schema Rules, Instance Document Rules, etc. See details in the UBL 1.0 Naming and Design Rules Checklist document, produced by members of the UBL Naming and Design Rules Subcommittee. The purpose of this UBL SC is "to recommend to the TC rules and guidelines for normative-form schema design, instance design, and markup naming, and write and maintain documentation of these rules and guidelines."

Schema Generation "The UBL 1.0 XSD schemas are the output of a transformation that applies schema construction rules to the Data Model represented by the UBL spreadsheets. The transformation process consisted of the following steps: (1) Reading in the data model spreadsheets; (2) Building from each spreadsheet an internal UML-based model; (3) Identifying external standards for code lists and including standard code list values as appropriate; (4) Applying UBL Naming and Design Rules; (5) Outputting conformant XSD schemas. A commercial CC-aware schema generation tool (GEFEG EDIFIX 5.0) was used to read the spreadsheets as UML data models, perform Q/A with them, and produce a schema representation adhering to the UBL 1.0 Naming and Design Rules."

Implementation Model "The implementation model of UBL represents the actual UBL XSD schemas as a UML model. This is produced by automatically transforming the schemas into a model conformant with the Unified Modeling Language (UML). This model is then used to produce a set of class diagrams that illustrate each of the main documents and several views of the reusable components. The automated transformation and diagram creation was performed using a commercial schema-to-UML transformation tool, Ontogenics hyperModel..."

Customization Guidelines "Guidelines for performing a compatible customization of UBL schemas, together with suggestions for how to proceed when a compatible customization is not possible are published in an independent document 'Guidelines for the Customization of UBL v1.0 Schemas.' Excerpt: UBL 1.0 contains document type definitions informed by the broad experience of members of the UBL Technical Committee, which includes both business and XML experts, and subsequent changes are therefore expected to be few and far between. However, one of the most important lessons learned from previous standards is that no business library is sufficient for all purposes. Requirements differ significantly amongst companies, industries, countries, etc., and a customization mechanism is therefore needed in many cases before the document types can be used in real-world applications. A primary motivation for moving from the relatively inflexible EDI formats to a more robust XML approach is the possibility of creating formal mechanisms for performing this customization while retaining maximum interoperability and validation... UBL proposes [implementation of a subsetting mechanism] through schema derivation... Thus UBL starts as generic as possible, with a set of schemas that supply all that is likely to be needed in the 80/20 or core case, which is UBL's primary target. Then it allows both subsetting and extension according to the needs of user communities, industries, nations, etc., according to what is permitted in the derivation mechanism [supported by XML Schema]..."

UBL Code List Schemas

Thirteen code list schemas required for UBL 1.0 are included in the UBL v1.0 package within the xsd/codelist directory. "These code list schemas allow component instances conformant to any of the main document schemas to be validated against code list values. Appendix E provides further information about the form of representation used for UBL code lists. A separate document Universal Business Language (UBL) Code List Representation, produced by the UBL Code List Subcommittee and edited by Marty Burns (National Institute of Standards and Technology - NIST), "provides rules for developing and using reusable code lists. This specification has been developed for the UBL Library and its derivations, but may also be used by other technologies and XML vocabularies as a mechanism for sharing code lists and for expressing code lists in W3C XML Schema form... Trading partners utilizing the Universal Business Language (UBL) must agree on restricted sets of coded values, termed 'code lists', from which values populate particular UBL data fields. Code lists are accessed using many technologies, including databases, programs and XML. Code lists are expressed in XML for UBL using W3C XML Schema for authoring guidance and processing validation purposes..."

Thirteen UBL code list schemas:

UBL and Core Components

UBL v1.0 is designed as "an implementation of ebXML Core Components Technical Specification 2.01 (CCTS) and the UBL Library uses XML schemas that are modular, reusable, and extensible in XML-aware ways." Of the six UBL Common Schemas, Common Basic Components (e.g., Amount, BackorderReason, BuildingName, CityName, Condition, CurrencyBaseRate, Date, DiscountPercent, HandlingInstructions, Measure, Percent, Quantity, StreetName, TimezoneOffset) and Common Aggregate Components contain the UBL library of reusable data components from which the main document schemas are assembled.

Schemas containing definitions needed to implement CCTS conformance include three Reusable Datatype Schemas: (1) The Core Component Types schema provides Core Component Types as defined by CCTS and are used to construct higher-level datatypes in a standardized and consistent manner; types include AmountType, BinaryObjectType, CodeType, DateTimeType, IdentifierType, IndicatorType, MeasureType, NumericType, QuantityType, and TextType. (2) Unspecialized Datatypes "defines Unqualified Data Types for primary and secondary representation terms as specified by CCTS; these XSD complexType structures are derived from Core Component Types and are the basic data types from which all other data types must derive." (3) The Specialized Datatypes schema provides Qualified Data Types as defined by CCTS. These XSD complexType structures are derived from Unspecialized Datatypes by extension, restriction, and other contextual constraints, such as facets. The Specialized Datatypes have been customized for the UBL 1.0 procurement process and may be further extended to support additional datatypes required for other business contexts." A Core Component Parameters schema also "defines the structure of the annotation/documentation sections that appear in all the other schemas, providing a consistent format for metadata such as object class, representation terms, semantic descriptions, and other supplementary information."

The following references provide information about core components background and ongoing development within the UBL TC:

About the OASIS UBL Technical Committee

The the OASIS UBL TC was chartered "to develop a standard library of XML business documents (purchase orders, invoices, etc.) by modifying an already existing library of XML schemas to incorporate the best features of other existing XML business libraries. The TC [would] then design a mechanism for the generation of context-specific business schemas through the application of transformation rules to the common UBL source library. UBL is intended to become an international standard for electronic commerce freely available to everyone without licensing or other fees..." [UBL TC home page]

"The goals of the UBL Technical Committee are as follows:

  • To create a Universal Business Language (UBL) that will standardize common business data structures and allow businesses of all sizes to enjoy the benefits of electronic commerce
  • To develop UBL in harmony with the OASIS ebXML specifications and in light of recommendations and standards issued by ISO, IEC, ITU, UN/ECE, W3C, IETF, OASIS, and other relevant standards bodies and organizations
  • To align the vocabulary and structures of UBL with the vocabulary and structures of existing XML business libraries
  • To establish liaisons with leading industry data exchange organizations in order to ensure the usability of UBL in a variety of trading contexts
  • To vest ownership of UBL 1.0 in OASIS, a nonprofit corporation dedicated to the adoption of structured information standards, and to make it freely available to everyone without licensing or other fees
  • To promote UBL to the status of an international standard for the conduct of XML-based electronic business
  • To develop a standard context methodology for the automated customization of UBL to fit different business environments..." [from the TC FAQ document]

Principal References
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2004-04-30-b.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org