UBL Maintenance Governance Procedures Version 1.1

The OASIS Universal Business Language (UBL) is an important and useful XML standard for exchanging business documents. The more the standard is implemented, the more requirements emerge for new areas of business. Therefore the OASIS Universal Business Language (UBL) TC has documented the processes by which UBL can be further enhanced to address additional requirements.

New and existing implementers analyze the UBL standard looking for a way to express their required business information in XML document structures. But no standard can be all things to all people. There inevitably will be information required for business processes that are not currently supported.

There are many ways implementers can resolve this situation. However, interoperability is inhibited if different approaches are used to address the same business requirements. Interoperability can be enhanced if UBL incorporates common solutions to accommodate these additional requirements.

This Committee Note provides guidance for UBL implementers to contribute proposals for additional business processes including additional document types or additional information requirements for consideration as candidates for the UBL standard. Significantly, these guidelines identify a process that allows implementers to apply their own solutions immediately within their current environment and still contribute these to future releases of UBL.

The aim of this Committee Note is to create security and certainty for organizations and communities investing in UBL implementations by documenting the governance procedures to ensure business requirements are met currently and into the future.

Finally, the document outlines the anticipated release cycle and time schedules for each phase of the OASIS standardization process. This will allow implementers to manage their expectations for candidate proposals and guide them in the timing of their submissions.

The OASIS Universal Business Language (UBL) TC is ultimately responsible for the maintenance, development and publication of the OASIS UBL standard. Appendix B, Current UBL resources contains contemporary information regarding specific resources of the UBL TC.

The committee has open membership to any OASIS member in good standing. Committee members are allowed to actively participate in any of the UBL subcommittees and task groups.

All committee members are welcome to propose suggestions for enhancements to UBL.

UBL TC members are urged to participate in reviewing work products.

See https://www.oasis-open.org/join for information on becoming an OASIS member and joining the UBL Technical Committee.

Voting at the UBL TC is possible only by committee members who are qualified for voting status at the time of the vote, as described in the OASIS Process.

Voting members are required to vote on all motions.

The committee also allows observer status to any OASIS member in good standing. Observers may attend meetings and subscribe (but not post) to the UBL TC mailing list.

This allows interested parties to monitor progress within the UBL TC.

The UBL TC follows the OASIS Technical Committee Process (referred to in this document as the “OASIS Process”) found at https://www.oasis-open.org/policies-guidelines/tc-process. The procedures in Section 6, “The pathway to standardization” of this Committee Note conform to the OASIS Process at the time of writing, but OASIS may produce updates that will need to be reflected as revisions to this Committee Note.

This section explains how to assist the UBL TC in processing your proposal.

It should be noted that a proposal that is incomplete or is a statement along the lines of “UBL should contain a...” will require more time to process than a proposal complete with the information the UBL TC needs to consider and implement the suggestions.

The UBL standard appears complex because of the wide-ranging scope of solutions where it plays a role. Those new to UBL may be unable to find an existing component to support their requirement, or they may create their own extension component unknowingly duplicating an existing component.

UBL has been in production for many years and has been tested and deployed in many organizations. As an example, in Denmark UBL for invoicing has been in production and required by law on a regional and national level for more than 15 years. Occasionally implementers in Denmark identify what they believe are new requirements. In many cases these are already addressed by the UBL standard, though perhaps in a different manner to how the implementers conceived them.

A proposal to include new document types into UBL would benefit from including the following details:

A submitter proposing new XML elements for UBL has the responsibility to describe in detail (or assist in describing) the supporting information required for the proposed element. These include the context of use and business case, the element’s type, proposed name, description, example values, and any equivalent business terms.

See Section 4.8, “Using the UBL extension point” for guidance adding the proposed elements in context as extensions to a given ABIE.

Each XML element in a UBL schema represents a component found in the equivalent UBL data model. These components are defined as Business Information Entities following the terminology from the ISO/TS 15000-5:2005 Core Component Technical Specification (CCTS). This specification is available at:

https://www.oasis-open.org/committees/document.php?document_id=6232.

Those proposers working with CCTS will find the UBL data model, the digital signature extension model and a prototypical empty model all available to be copied as proforma models with which to create new proposals.

http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#A-THE-UBL-2.1-DATA-MODEL contains useful information about the data modeling concepts used in UBL.

For guidance on the many CCTS fields in the model columns of the spreadsheet, please review the latest version of the UBL Naming and Design Rules Version 3.1:

It is required that proposals for enhancements preserve backward compatibility with the previous version of UBL. This is enforced through rules on the acceptable cardinality of proposed changes to elements.

The cardinality of a UBL element means the number of times the element is allowed to exist at the particular point in the document tree (between the immediately-preceding element of another name and the immediately-following element of another name).

Cardinality applies to leaf and branch elements of the document tree.

There are four possible values for cardinality:

In order to preserve backward compatibility with all previous versions of UBL, the cardinality of all proposed new or modified elements is strictly controlled.

For example, backward compatibility means that every conceivable schema-valid instance of UBL 2.0 also is a schema-valid instance of UBL 2.1 and all subsequent minor revisions of UBL. Similarly every schema-valid instance of UBL 2.1 also shall be a schema-valid instance of UBL 2.2 and all subsequent minor revisions of UBL.

The following cardinality scenarios are mandated to preserve backward compatibility:

Therefore any proposed changes to existing elements should be as follows:

Guaranteeing forward compatibility is not practical because of the additional elements in forward releases. For example, a UBL 2.1 instance is not guaranteed to be a schema-valid instance of UBL 2.0 because it may contain an element not defined in UBL 2.0.

However it is true that a user of UBL 2.1 choosing only to use UBL 2.0 elements in the UBL 2.1 document will have an instance that is schema-valid with the UBL 2.0 schemas. The UBL Customization Guidelines at http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1.0cs01.pdf makes reference to potential forward-compatible processing by pruning from a document those elements that a system does not recognize.

UBL is a transactional data language and as such there is no concept of “paragraphs of text”, “field lengths” or other presentational facets.

A single element of a textual data type is a continuous string of text from the start tag of the element to the end tag of the element without any formatting characteristics.

UBL does support repeating textual elements but only where the same information may be required in different languages. These are not designed to convey different sets of information – such as different paragraphs or lines.

Therefore a proposal for a textual element (such as a description) may have multiple cardinality but if repeated each instance should contain different translations of the same information (indicated by a language identifier).

All UBL document schemas provide an extension point to accommodate additional information elements. This extension point provides a technical solution for custom requirements to be met within standard UBL documents. In UBL 2.0, 2.1, and 2.2 there is a single extension point found at the beginning of the document element so as to be encountered in a serial parsing of the document before elements that the extension point may influence. In UBL 2.3 and subsequent releases there are additional extension points, one found at the beginning of every manifest ASBIE of the document. This is every element that, itself, has element children also has an optional UBL extension point as the first of all its element children.

It should be noted that interoperability is inhibited if each implementer uses the extension point syntax differently to express the same requirement. Accordingly, it behooves industry sectors or other UBL communities to agree amongst themselves how non-UBL content is to be expressed, and where it is to be expressed, in a UBL document.

The sender of a document cannot be guaranteed that the receiver of the document recognizes any extension. Thus, it is important not to require processing of any given extension for the successful processing of the document itself. Extensions should be used only for additional information that the receiver may be in a position to access.

The UBL extension point is useful when proposing to the committee that new elements be included in the UBL specification. One can create illustrative test documents including the proposed new elements in the context of the ABIE in which the proposal is being made by using that ABIE’s extension point where manifest.

Namespaces are critically important in XML, and thus are critically important in UBL. Unfortunately, the simple concept embodied by XML namespaces is often misunderstood, leading to confusion with users. Regrettably, the verbose nature of UBL namespaces contributes to the mistaken impression that the namespaces somehow are adding to the complexity of the XML in UBL documents.

This Committee Note does not attempt to explain the technical declaration syntax for XML namespaces. See Appendix C, Declaring namespaces for more details regarding choosing and using namespaces.