UBL Maintenance Governance Procedures Version 1.0

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.

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 10 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.

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.0 found at:

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

If at all possible proposals for enhancements should 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 is also a schema-valid instance of UBL 2.1 and all subsequent minor revisions of UBL. Similarly every schema-valid instance of UBL 2.1 shall also 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.

However, interoperability is inhibited if each implementer uses the extension point syntax differently to express the same requirement.

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.

A proposal to the UBL Technical Committee may also benefit from including representative XML schemas that satisfy the requirements of the proposal. These may be those used in an actual implementation by the proposer.

If the proposer wishes to submit demonstration schemas that remain compatible with existing UBL document types, then the proposed new components must be implemented as UBL Extensions.