This note is related to Universal Business Language Version 2.1. OASIS Standard. http://docs.oasis-open.org/ubl/UBL-2.1.html.
This document was last revised or approved by the UBL TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at https://www.oasis-open.org/committees/ubl/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page at https://www.oasis-open.org/committees/ubl/ipr.php.
See Appendix A, Release Notes for more information regarding this release package.
When referencing this note the following citation format should be used:
[UBL-conformance-to-CCTS] UBL Conformance to ebXML CCTS ISO/TS 15000-5:2005 Version 1.0. Edited by Tim McGrath and G. Ken Holman. 08 May 2014. OASIS Committee Note 01. http://docs.oasis-open.org/ubl/UBL-conformance-to-CCTS/v1.0/cn01/UBL-conformance-to-CCTS-v1.0-cn01.html. Latest version: http://docs.oasis-open.org/ubl/UBL-conformance-to-CCTS/v1.0/UBL-conformance-to-CCTS-v1.0.html.
Copyright © OASIS Open 2014. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name “OASIS” is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark.php for guidance.
On at least two occasions in the past 11 years (2003 and 2007) the UBL TC has had to justify our claims of conformance to the Core Components Technical Specification (CCTS) . This Committee Note makes the informal responses given in the past formal and makes them available to interested parties so as to avoid misunderstandings in the future.
It should also be understood that all references to CCTS in UBL are to ISO/TS 15000-5:2005 published by UN/CEFACT in 2003 as the “Core Components Technical Specification – Part 8 of the ebXML Framework”. UBL makes no claims with respect to the recently published ISO 15000-5:2014 version but have been assured by its authors that ISO 15000-5:2014 retains backward compatibility with ISO/TS 15000-5:2005.
Core Components Technical Specification
Electronic Business Extensible Markup Language
Universal Business Language
 A statement of intent to implement the UN/CEFACT Core Component Technical Specification (April 2003): https://www.oasis-open.org/committees/document.php?document_id=1705&wg_abbrev=ubl-lcsc
 UBL has been the subject of a Masters Thesis “UN/CEFACT CCTS Based e-Business Document Design Aand Customization Environment for Achieving Data Interoperability” (2009) http://www.srdc.com.tr/projects/isurf/index.php?option=com_docman&task=doc_download&gid=170&Itemid=61
 UBL's current status with respect to schemas for implementing Core Component Types (June 2004): https://www.oasis-open.org/apps/org/workgroup/ubl/download.php/7206/draft-mcgrath-UBLandCCTSschemas.pdf
 UBL candidate Core Components for UN/CEFACT CCL (March 2007): https://www.oasis-open.org/apps/org/workgroup/ubl/download.php/22994/UBL%20Candidate%20CC%20Draft%200%201-16032007.zip
 UN/CEFACT ebXML Core Components Technical Specification Approved for Implementation Verification (December 2002): http://xml.coverpages.org/ni2002-12-19-a.html
 Universal Business Language: Realizing eBusiness XML (2002): http://xml.coverpages.org/Crawford-UBL200212.pdf
 Available tools that support UBL (April 2014): http://ubl.xml.org/products
[CCTS] ISO/TS 15000-5:2005 Electronic Business Extensible Markup Language (ebXML)— Part 5: ebXML Core Components Technical Specification, Version 2.01 (identical to Part 8 of the ebXML Framework)
[UPCC] UML Profile for Core Components Version 1.0 2008-01-16
Section 4.3 of the Core Component Technical Specification [CCTS] defines conformance as follows:
"Applications will be considered to be in full conformance with this technical specification if they comply with the content of normative sections, rules and definitions.
[A1] Conformance shall be determined through adherence to the content of normative sections, rules and definitions."
The normative sections, rules and definitions for the CCTS are contained in:
Section 6: Technical Details - Core Components and Context [normative]
Section 7: Technical Details - Storage and Metadata [normative]
Section 8: Technical Details - Permissible Representation Terms and Approved Core Component Type, Content, and Supplementary Components [normative]
Section 9: Definition of Terms [normative]
As many readers will appreciate, some of the text in the normative clauses of the CCTS may be subject to different interpretations. It is possible that two conforming implementations of CCTS could produce different results (a phenomenon not unusual in semantic standards). We have witnessed this with the Core Component Libraries used by other groups such as UN/CEFACT and WCO each taking slightly differing interpretations of the text in some clauses.
We maintain that these different implementations can all be conforming to the CCTS as they all satisfy the normative clauses of the standard. We believe UBL conforms to the CCTS but may not be implemented in exactly the same way as other conforming implementations.
In short, conformance to the normative clauses is not easily verified. To address the issue of formal assessment of conformance to their standards, UN/CEFACT has recently commenced a project to address “Conformance and interoperability of standards”. This project will investigate how self-conformance statements should be specified and be made publicly available to enable transparency in reporting how standards are implemented, especially in respect of solutions involving common semantics and re-usable data models that are technology neutral. UBL intends to contribute our self-conformance statements to this UN/CEFACT project.
We believe the answer is “YES”.
The UBL TC believes that there is a broad consensus in the standards and user community that UBL is a valid implementation of the CCTS  . UBL was an early adopter of CCTS (probably the first) and was actually used as implementation verification for the CCTS standard itself .
UBL has been a strong promoter of the value of using CCTS and is often cited as a reference implementation .
However, there are some common misunderstandings often discussed regarding UBL and its conformance to the CCTS.
The most common misunderstanding regards the use of Core Components in the UBL library.
A core component (CC) is a building block for the creation of a semantically correct and meaningful information exchange package. It contains only the information pieces necessary to describe a specific concept. A BIE (business information entity) is a piece of business data or a group of pieces of business data with a unique business semantic definition. Not surprisingly, the Core Component Technical Specification expects that all BIEs are based on Core Components.
The CCTS states (in Section 9 – Definition of Terms) that BIEs are derived from CCs. This means their existence is established by the definition of a BIE. That is tautological; by definition, a BIE is always based on a CC - even if that CC is not explicitly instantiated. It is somewhat equivalent to saying language must be based on a grammar – even if we do not publish that grammar, we know it exists.
Since the beginning the UBL TC has always maintained that our library and associated Schemas are based on Core Components (otherwise we could not create the BIEs that are published in the UBL Schemas).
We claim that every UBL BIE is based on a Core Component. However, UBL does not instantiate or publish its abstract model of Core Components, we only publish the derived BIEs. This practice does not contravene any clauses of the CCTS. The CCTS does not mandate publication of Core Components, only that they exist and that BIEs are based upon them.
There is a simple reason why we chose to do this.
It is important to recognize that the normative parts of UBL are the XML Schemas and not the models from which the Schemas are derived. The decision of the UBL TC was that the users of our normative XML Schemas would be confused by the publication of both abstract CCs (which are not used in the Schemas) and also the BIE expression for these. These two libraries are highly repetitive (almost a one-to-one correlation) and in reality it is only the BIEs that appear in the normative XML Schemas of UBL and not the CCs that they are derived from. Adding CCs would make the specifications unnecessarily complex. History has proven this to be the case. No-one implementing UBL BIEs has asked about the Core Components they were based on.
This topic has been raised several times in the history of UBL’s work, most recently in 2007 when we had guidance from the UN/CEFACT Core Component Working Group that this was a valid interpretation of the specification. To demonstrate this in 2007 the UBL TC provided UN/CEFACT with our Core Components for harmonization with the UN/CEFACT Core Component Library .
Clearly there is no validity to the claim that UBL does not use Core Components.
This is another commonly misunderstood aspect of conformance to the CCTS.
In this section emphasis in quoted excerpts is added by the editors for highlight purposes and does not appear as emphasis in the original document.
Consider the following two items:
(a) the statement in Section 4.1 “Scope and Focus” that reads:
"This specification will form the basis for standards development work of business analysts, business users and information technology specialists supplying the content of and implementing applications that will employ the UN/CEFACT Core Component Library (CCL). The Core Component Library will be stored in a UN/CEFACT repository and identified in an ebXML compliant registry."
(b) the description in Section 5.1.1 “Discovery” that reads:
"An important aspect of information interoperability is that each Business Information Entity is based upon a Core Component structure and associated semantic definitions derived from the Core Component Library."
Some people have interpreted (a) and (b) to suggest that there can only be one universal Core Component Library and that it is from UN/CEFACT. This would also mean that all BIEs must be derived from only those UN/CEFACT-defined Core Components.
However this interpretation is contradicted in other sections, such as the note to [C1] that reads:
"The Core Components Dictionary is one of several ways that Core Components are to be made available."
And again in Section 6.1.5, that states:
"all Core Components will be recorded in an ebXML compliant registry and stored in a related repository."
And the note in section 4.2 where there is reference to future supplemental documents "that may be used in conjunction with this Core Components Technical Specification" including:
"Core Components Primer – details how the contents of Sections 5, 6, and 7 would be used in practice to create a library of Core Components and Business Information Entities."
The UBL TC maintains that using only the Core Components from the UN/CEFACT Core Component Library is not a mandatory requirement for implementing the CCTS. We believe that the CCTS is not bound to any specific library of Core Components. It is a methodology.
Re-reading the text in section 4.1 we understand that it refers to the UN/CEFACT Core Component Library as an example of one use of the CCTS. This interpretation is also supported by Section 4.2, 6.1.5 and [C1] of the CCTS. It also agrees with other UN/CEFACT publications such as the “UML Profile for Core Components” [UPCC] which states that:
“Dependencies between a CCLibrary and other Libraries can be expressed using the standard UML dependency. The given example uses the core components library published by TBG17:”
Therefore, it is acceptable for UBL to maintain its own Library (of BIEs and implied Core Components) and not rely solely on the Core Components from UN/CEFACT. It is also realistic because the UBL Library was actually created before work commenced on the UN/CEFACT Core Component Library.
To promote re-use of common Core Components UBL has provided UN/CEFACT with our ‘candidate’ Core Component Library for harmonization into their Library .
To further encourage alignment UBL has also chosen to include the UN/CEFACT Core Component Type Schema to support interoperability between entities also defined using the same UN/CEFACT Core Component Type Schema .
The UBL TC believes that the CCTS is a valuable tool for creating eBusiness vocabularies and UBL has contributed to its development.
We believe we are fully conformant to the normative clauses in the CCTS and have been for several years.
We believe UBL has helped raise the profile of CCTS and promoted its adoption in other domains. We have also stimulated the development of open-source tools and technologies  to support CCTS users.
The UBL TC trusts this Committee Note will address any further misunderstandings with respect to CCTS conformance.
Online and downloadable versions of this release are available from the locations specified at the top of this document.
This OASIS Committee Note is published as a zip archive in the http://docs.oasis-open.org/ubl/UBL-conformance-to-CCTS/v1.0/cn01/ directory. Unzipping this archive creates a directory tree containing a master DocBook XML file (UBL-conformance-to-CCTS-v1.0-cn01.xml), a generated hypertext version of this file (UBL-conformance-to-CCTS-v1.0-cn01.html), a generated PDF version of this file (UBL-conformance-to-CCTS-v1.0-cn01.pdf), and a publication subdirectory. Note that while the UBL-conformance-to-CCTS-v1.0-cn01.xml file is the “original” of this specification, it may not be viewable in all currently available web browsers.
DocBook documentation support files
UBL is a volunteer project of the international business community. Inquiries regarding UBL may be posted to the public ubl-dev list, archives for which are located at
Subscriptions to ubl-dev can be made through the OASIS list manager at
OASIS provides an official community gathering place and information resource for UBL at
The following persons contributed to the work of the committee during the preparation of this work product.
|Oriol Bausa Peris, Individual|
|Kenneth Bengtsson, Alfa1lab|
|Peter Borresen, Document Engineering Services Limited|
|Jon Bosak, Individual|
|Kees Duvekot, RFS Holland Holding B.V.|
|G. Ken Holman, Crane Softwrights Ltd.|
|Ole Madsen, Danish Agency for Digitisation, Ministry of Finance|
|Tim McGrath, Document Engineering Services Limited|
|Andrew Schoka, Individual|
Copyright © OASIS Open 2014. All rights reserved.
|08 May 2014|