19 July 2006 cd-UBL-NDR-2.0 Mavis Cournane,

Cognitran Limited

mavis.Cournane@cognitran.com Mike Grimley

US Navy

MJGrimley@acm.org 2001 2002 2003 2004 The Organization for the Advancement of Structured Information Standards [OASIS] Mark Crawford SAP Bill Burcham, Sterling Commerce Fabrice Desré, France Telecom Matt Gertner, Schemantix Jessica Glace, LMI Arofan Gregory, Aeon LLC Michael Grimley, US Navy Eduardo Gutentag, Sun Microsystems Sue Probert, CommerceOne Gunther Stuhec, SAP Paul Thorpe, OSS Nokalva Jim Wilson, CIDX Past Chair Eve Maler, Sun Microsystems <eve.maler@sun.com> This specification documents the naming and design rules and guidelines for the construction of XML components for the UBL vocabulary. Copyright © 2001, 2002, 2003, 2004 The Organization for the Advancement of Structured Information Standards [OASIS]

This document has been approved by the OASIS Universal Business Language Technical Committee as a Committee Draft and is submitted for consideration as an OASIS Standard

XML is often described as the lingua franca of e-commerce. The implication is that by standardizing on XML, enterprises will be able to trade with anyone, any time, without the need for the costly custom integration work that has been necessary in the past. But this vision of XML-based “plug-and-play” commerce is overly simplistic. Of course XML can be used to create electronic catalogs, purchase orders, invoices, shipping notices, and the other documents needed to conduct business. But XML by itself doesn't guarantee that these documents can be understood by any business other than the one that creates them. XML is only the foundation on which additional standards can be defined to achieve the goal of true interoperability. The Universal Business Language (UBL) initiative is the next step in achieving this goal. The task of creating a universal XML business language is a challenging one. Most large enterprises have already invested significant time and money in an e-business infrastructure and are reluctant to change the way they conduct electronic business. Furthermore, every company has different requirements for the information exchanged in a specific business process, such as procurement or supply-chain optimization. A standard business language must strike a difficult balance, adapting to the specific needs of a given company while remaining general enough to let different companies in different industries communicate with each other. The UBL effort addresses this problem by building on the work of the electronic business XML (ebXML) initiative. The ebXML effort, currently continuing development in the Organization for the Advancement of Structured Information Standards (OASIS), is an initiative to develop a technical framework that enables XML and other payloads to be utilized in a consistent manner for the exchange of all electronic business data. UBL is organized as an OASIS Technical Committee to guarantee a rigorous, open process for the standardization of the XML business language. The development of UBL within OASIS also helps ensure a fit with other essential ebXML specifications. UBL will be promoted to the level of international standard. The UBL Technical Committee has established the UBL Naming and Design Rules Subcommittee with the charter 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". Accordingly, this specification documents the rules and guidelines for the naming and design of XML components for the UBL library. It contains only rules that have been agreed on by the OASIS UBL Naming and Design Rules Subcommittee (NDR SC). Proposed rules, and rationales for those that have been agreed on, appear in the accompanying NDR SC position papers, which are available at http://www.oasis-open.org/committees/ubl/ndrsc/.

This document has several primary and secondary targets that together constitute its intended audience. Our primary target audience is the members of the UBL Technical Committee. Specifically, the UBL Technical Committee will use the rules in this document to create normative form schema for business transactions. Developers implementing ebXML Core Components may find the rules contained herein sufficiently useful to merit adoption as, or infusion into, their own approaches to ebXML Core Component based XML schema development. All other XML Schema developers may find the rules contained herein sufficiently useful to merit consideration for adoption as, or infusion into, their own approaches to XML schema development.

This specification conveys a normative set of XML schema design rules and naming conventions for the creation of business based XML schema for business documents being exchanged between two parties using XML constructs defined in accordance with the ebXML Core Components Technical Specification.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2119. Non-capitalized forms of these words are used in the regular English sense. Definition A formal definition of a term. Definitions are normative. Example A representation of a definition or a rule. Examples are informative. Note Explanatory information. Notes are informative. RRRn Identification of a rule that requires conformance to ensure that an XML Schema is UBL conformant. The value RRR is a prefix to categorize the type of rule where the value of RRR is as defined in Table 1 and n (1..n) indicates the sequential number of the rule within its category. In order to ensure continuity across versions of the specification, rule numbers that are deleted in future versions will not be re-issued, and any new rules will be assigned the next higher number – regardless of location in the text. Future versions will contain an appendix that lists deleted rules and the reason for their deletion. Only rules and definitions are normative; all other text is explanatory. Figure 1 - Rule Prefix Token Value Rule Prefix Token Value ATD Attribute Declaration ATN Attribute Naming CDL Code List CTD ComplexType Definition DOC Documentation ELD Element Declaration ELN Element Naming GNR General Naming GTD General Type Definition GXS General XML Schema IND Instance Document MDC Modeling Constraints NMC Naming Constraints NMS Namespace RED Root Element Declaration SSM Schema Structure Modularity STA Standards Adherence VER Versioning Bold – The bolding of words is used to represent example names or parts of names taken from the library. Courier – All words appearing in courier font are values, objects, and keywords. Italics – All words appearing in italics, when not titles or used for emphasis, are special terms defined in Appendix C. Keywords – keywords reflect concepts or constructs expressed in the language of their source standard. Keywords have been given an identifying prefix to reflect their source. The following prefixes are used: xsd: – represents W3C XML Schema Definition Language. If a concept, the words will be in upper camel case, and if a construct, they will be in lower camel case. xsd: – complexType represents an XSD construct xsd: – SchemaExpression represents a concept ccts: – represents ISO 15000-5 ebXML Core Components Technical Specification ubl: – represents the OASIS Universal Business Language The terms “W3C XML Schema” and “XSD” are used throughout this document. They are considered synonymous; both refer to XML Schemas that conform to Parts 1 and 2 of the W3C XML Schema Definition Language (XSD) Recommendations. See Appendix C for additional term definitions.

The UBL guiding principles encompass three areas: General UBL guiding principles Extensibility Code generation

The UBL Technical Committee has approved a set of high-level guiding principles. The UBL Naming and Design Rules Subcommittee (NDRSC) has followed these high-level guiding principles for the design of UBL NDR. These UBL guiding principles are: Internet Use – UBL shall be straightforwardly usable over the Internet. Interchange and Application Use – UBL is intended for interchange and application use. Tool Use and Support – The design of UBL will not make any assumptions about sophisticated tools for creation, management, storage, or presentation being available. The lowest common denominator for tools is incredibly low (for example, Notepad) and the variety of tools used is staggering. We do not see this situation changing in the near term. Legibility – UBL documents should be human-readable and reasonably clear. Simplicity – The design of UBL must be as simple as possible (but no simpler). 80/20 Rule – The design of UBL should provide the 20% of features that accommodate 80% of the needs. Component Reuse –The design of UBL document types should contain as many common features as possible. The nature of e-commerce transactions is to pass along information that gets incorporated into the next transaction down the line. For example, a purchase order contains information that will be copied into the purchase order response. This forms the basis of our need for a core library of reusable components. Reuse in this context is important, not only for the efficient development of software, but also for keeping audit trails. Standardization – The number of ways to express the same information in a UBL document is to be kept as close to one as possible. Domain Expertise – UBL will leverage expertise in a variety of domains through interaction with appropriate development efforts. Customization and Maintenance – The design of UBL must facilitate customization and maintenance. Context Sensitivity – The design of UBL must ensure that context-sensitive document types aren’t precluded. Prescriptiveness – UBL design will balance prescriptiveness in any single usage scenario with prescriptiveness across the breadth of usage scenarios supported. Having precise, tight content models and datatypes is a good thing (and for this reason, we might want to advocate the creation of more document type “flavors” rather than less). However, in an interchange format, it is often difficult to get the prescriptiveness that would be desired in any single usage scenario. Content Orientation – Most UBL document types should be as “content-oriented” (as opposed to merely structural) as possible. Some document types, such as product catalogs, will likely have a place for structural material such as paragraphs, but these will be rare. XML Technology – UBL design will avail itself of standard XML processing technology wherever possible (XML itself, XML Schema, XSLT, XPath, and so on). However, UBL will be cautious about basing decisions on “standards” (foundational or vocabulary) that are works in progress. Relationship to Other Namespaces – UBL design will be cautious about making dependencies on other namespaces. UBL does not need to reuse existing namespaces wherever possible. For example, XHTML might be useful in catalogs and comments, but it brings its own kind of processing overhead, and if its use is not prescribed carefully it could harm our goals for content orientation as opposed to structural markup. Legacy formats – UBL is not responsible for catering to legacy formats; companies (such as ERP vendors) can compete to come up with good solutions to permanent conversion. This is not to say that mappings to and from other XML dialects or non-XML legacy formats wouldn’t be very valuable. Relationship to xCBL – UBL will not be a strict subset of xCBL, nor will it be explicitly compatible with it in any way. XML Common Business Library (xCBL) is a set of XML business documents and their components.

Many e-commerce document types are, broadly speaking, useful but require minor structural modifications for specific tasks or markets. When a truly common XML structure is to be established for e-commerce, it needs to be easy and inexpensive to modify. Many data structures used in e-commerce are very similar to ’standard‘ data structures, but have some significant semantic difference native to a particular industry or process. In traditional Electronic Data Interchange (EDI), there has been a gradual increase in the number of published components to accommodate market-specific variations. Handling these variations are a requirement, and one that is not easy to meet. A related EDI phenomenon is the overloading of the meaning and use of existing elements, which greatly complicates interoperation. To avoid the high degree of cross-application coordination required to handle structural variations common to EDI and XML based systems–it is necessary to accommodate the required variations in basic data structures without either overloading the meaning and use of existing data elements, or requiring wholesale addition of new data elements. This can be accomplished by allowing implementers to specify new element types that inherit the properties of existing elements, and to also specify exactly the structural and data content of the modifications. This approach can be expressed by saying that extensions of core elements are driven by context. ebXML, Core Components Technical Specification – Part 8 of the ebXML Technical Framework, V2.01, 15 November, 2003 Context driven extensions should be renamed to distinguish them from their parents, and designed so that only the new elements require new processing. Similarly, data structures should be designed so that processes can be easily engineered to ignore additions that are not needed. The UBL context methodology is discussed in the Guidelines for the Customization of UBL Schemas available as part of UBL 1.0.

The UBL NDR makes no assumptions on the availability or capabilities of tools to generate UBL conformant XSD Schemas. In conformance with UBL guiding principles, the UBL NDR design process has scrupulously avoided establishing any naming or design rules that sub-optimize the UBL schemas in favor of tool generation. Additionally, in conformance with UBL guiding principles, the NDR is sufficiently rigorous to avoid requiring human judgment at schema generation time.

The W3C XML Schema Definition Language has become the generally accepted schema language that is experiencing the most widespread adoption. Although other schema languages exist that offer their own advantages and disadvantages, UBL has determined that the best approach for developing an international XML business standard is to base its work on W3C XSD. All UBL schema design rules MUST be based on the W3C XML Schema Recommendations: XML Schema Part 1: Structures and XML Schema Part 2: Datatypes. A W3C technical specification holding recommended status represents consensus within the W3C and has the W3C Director's stamp of approval. Recommendations are appropriate for widespread deployment and promote W3C's mission. Before the Director approves a recommendation, it must show an alignment with the W3C architecture. By aligning with W3C specifications holding recommended status, UBL can ensure that its products and deliverables are well suited for use by the widest possible audience with the best availability of common support tools. All UBL schema and messages MUST be based on the W3C suite of technical specifications holding recommendation status.

UBL employs the methodology and model described in Core Components Technical Specification, Part 8 of the ebXML Technical Framework, Version 2.01 of 15 November 2003 (CCTS) to build the UBL Component Library. The Core Components work is a continuation of work that originated in, and remains a part of, the ebXML initiative. The Core Components concept defines a new paradigm in the design and implementation of reusable syntactically neutral information building blocks. Syntax neutral Core Components are intended to form the basis of business information standardization efforts and to be realized in syntactically specific instantiations such as ANSI ASC X12, UN/EDIFACT, and XML representations such as UBL. The essence of the Core Components specification is captured in context neutral and context specific building blocks. The context neutral components are defined as Core Components (ccts:CoreComponents). Context neutral ccts:CoreComponents are defined in CCTS as “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.” Core Components Technical Specification, Part 8 of the ebXML Technical Framework Version 2.0 (Second Edition), UN/CEFACT, 15 November 2003 Figure 2-1 illustrates the various pieces of the overall ccts:CoreComponents metamodel. The context specific components are defined as Business Information Entities (ccts:BusinessInformationEntities). See CCTS Section 6.2 for a detailed discussion of the ebXML context mechanism. Context specific ccts:BusinessInformationEntities are defined in CCTS as “A piece of business data or a group of pieces of business data with a unique Business Semantic definition.” Core Components Technical Specification, Part 8 of the ebXML Technical Framework Version 2.0 (Second Edition), UN/CEFACT, 15 November 2003 Figure 2-2 illustrates the various pieces of the overall ccts:BusinessInformationEntity metamodel and their relationship with the ccts:CoreComponents metamodel. As shown in Figure 2-2, there are different types of ccts:CoreComponents and ccts:BusinessInformationEntities. Each type of ccts:CoreComponent and ccts:BusinessInformationEntity has specific relationships between and amongst the other components and entities. The context neutral ccts:CoreComponents are the linchpin that establishes the formal relationship between the various context-specific ccts:BusinessInformationEntities.

UBL consists of a library of ccts:BusinessInformationEntities. In creating this library, UBL has defined how each of the ccts:BusinessInformationEntity components map to an XSD construct (See figure 2-3). In defining this mapping, UBL has analyzed the CCTS metamodel and determined the optimal usage of XSD to express the various ccts:BusinessInformationEntity components. As stated above, a

ccts:BusinessInformationEntity can be a ccts:AggregateBusinessInformationEntity, a ccts:BasicBusinessInformationEntity, or a ccts:AssociationBusinessInformationEntity. In understanding the logic of the UBL binding of ccts:BusinessInformationEntities to XSD expressions, it is important to understand the basic constructs of the ccts:AggregateBusinessInformationEntities and their relationships as shown in Figure 2-2. Both Aggregate and Basic Business Information Entities must have a unique name (Dictionary Entry Name). The ccts:AggregateBusinessInformationEntities are treated as objects and are defined as xsd:complexTypes. The ccts:BasicBusinessInformationEntities are treated as attributes of the ccts:AggregateBusinessInformationEntity and are found in the content model of the ccts:AggregateBusinessInformationEntity as a referenced xsd:element. The ccts:BasicBusinessInformationEntities are based on a reusable ccts:BasicBusinessInformationEntityProperty which are defined as xsd:complexTypes. A Basic Business Information Entity Property represents an intrinsic property of an Aggregate Business Information Entity. Basic Business Information Entity properties are linked to a Datatype. UBL uses two types of Datatypes – unqualified that are provided by the UN/CEFACT Unqualified Datatype (udt) schema module, and qualified datatypes that are defined by UBL. UBL’s use of the UN/CEFACT Unqualified Datatype schema module is primarily confined to its importation. It must not be assumed that UBL’s adoption of the UDT schema module extends to any of ATG’s rules that have a bearing on the use of the UDT. The ccts:UnqualifiedDatatypes correspond to ccts:RepresentationTerms. The ubl:QualifiedDatatypes are derived from ccts:UnqualifiedDatatypes with restrictions to the allowed values or ranges of the corresponding ccts:ContentComponent or ccts:SupplementaryComponent. CCTS defines an approved set of primary and secondary representation terms. However, these representation terms are simply naming conventions to identify the Datatype of an object, not actual constructs. These representation terms are in fact the basis for Datatypes as defined in the CCTS. A ccts:Datatype “defines the set of valid values that can be used for a particular Basic Core Component Property or Basic Business Information Entity Property Datatype” Core Components Technical Specification, Part 8 of the ebXML Technical Framework Version 2.0 (Second Edition), UN/CEFACT, 15 November 2003 The ccts:Datatypes can be either unqualified—no restrictions applied—or qualified through the application of restrictions. The sum total of the datatypes is then instantiated as the basis for the various XSD simple and complex types defined in the UBL schemas. CCTS supports datatypes that are qualified, i.e. it enables users to define their own datatypes for their syntax neutral constructs. Thus ccts:Datatypes allow UBL to identify restrictions for elements when restrictions to the corresponding ccts:ContentComponent or ccts:SupplementaryComponent are required. There are two kinds of Business Information Entity Properties - Basic and Association. A ccts:AssociationBusinessInformationEntityProperty represents an extrinsic property – in other words an association from one ccts:AggregateBusinessInformationEntityProperty instance to another ccts:AggregateBusinessInformationEntityProperty instance. It is the ccts:AggregateBusinessInformationEntityProperty that expresses the relationship between ccts:AggregateBusinessInformationEntities. Due to their unique extrinsic association role, ccts:AssociationBusinessInformationEntities are not defined as xsd:complexTypes, rather they are either declared as elements that are then bound to the xsd:complexType of the associated ccts:AggregateBusinessInformationEntity, or they are reclassified ABIEs. As stated above, ccts:BasicBusinessInformationEntities define the intrinsic structure of a ccts:AggregateBusinessInformationEntity. These ccts:BasicBusinessInformationEntities are the “leaf” types in the system in that they contain no ccts:AssociationBusinessInformationEntity properties. A ccts:BasicBusinessInformationEntity must have a ccts:CoreComponentType. All ccts:CoreComponentTypes are low-level types, such as Identifiers and Dates. A ccts:CoreComponentType describes these low-level types for use by ccts:CoreComponents, and (in parallel) a ccts:Datatype, corresponding to that ccts:CoreComponentType, describes these low-level types for use by ccts:BusinessInformationEntities. Every ccts:CoreComponentType has a single ccts:ContentComponent and one or more ccts:SupplementaryComponents. A ccts:ContentComponent is of some Primitive Type. Allccts:CoreComponentTypes and their corresponding content and supplementary components are pre-defined in the CCTS. UBL has developed an xsd:SchemaModule that defines each of the pre-defined ccts:CoreComponentTypes as an xsd:complexType or xsd:simpleType and declares ccts:SupplementaryComponents as an xsd:attribute or uses the predefined facets of the built-in xsd:Datatype for those that are used as the base expression for an xsd:simpleType. UBL continues to work with UN/CEFACT and the Open Applications Group to develop a single normative schema for representing ccts:CoreComponentTypes.

This chapter defines UBL rules related to general XML constructs to include: Overall Schema Structure Naming and Modeling Constraints Reusability Scheme Namespace Scheme Versioning Scheme Modularity Strategy Annotation and Documentation Requirements

A key aspect of developing standards is to ensure consistency in their development. Since UBL is envisioned to be a collaborative standards development effort, with liberal developer customization opportunities through use of the xsd:extension and xsd:restriction mechanisms, it is essential to provide a mechanism that will guarantee that each occurrence of a UBL conformant schema will have the same look and feel. Link to Profile

[Definition] Document schema – The overarching schema within a specific namespace that conveys the business document functionality of that namespace. The document schema declares a target namespace and is likely to xsd:include internal schema modules or xsd:import external schema modules. Each namespace will have one, and only one, document schema. In order to facilitate the management and reuse of UBL constructs, all global elements, excluding the root element of the document schema must reside in either the CAC or CBC schema modules. Link to Profile

A key aspect of UBL is to base its work on process modeling and data analysis as precursors to developing the UBL library. In determining how best to affect this work, several constraints have been identified that directly impact both the process modeling and data analysis, and the resultant UBL Schema.

A primary aspect of the UBL library documentation are its spreadsheet models. The entries in these spreadsheet models fully define the constructs available for use in UBL business documents. These spreadsheet entries contain fully conformant CCTS dictionary entry names as well as truncated UBL XML element names developed in conformance with the rules in section 4. The dictionary entry name ties the information to its standardized semantics, while the name of the corresponding XML element is only shorthand for this full name. The rules for element naming and dictionary entry naming are different. Link to Profile The fully qualified path anchors the use of that construct to a particular location in a business message. The definition of the construct identifies any semantic dependencies that the FQP has on other elements and attributes within the UBL library that are not otherwise enforced or made explicit in its structural definition.

In keeping with UBL guiding principles, modeling constraints are limited to those necessary to ensure consistency in development of the UBL library.

UBL is based on instantiating ebXML ccts:BusinessInformationEntities. UBL models and the XML expressions of those models are class driven. Specifically, the UBL library defines classes for each ccts:AggregateBusinessInformationEntity and the UBL schemas instantiate those classes. The attributes of those classes consist of ccts:BasicBusinessInformationEntities.

Each ccts:BasicBusinessInformationEntity has an associated ccts:CoreComponentType. The CCTS specifies an approved set of ccts:CoreComponentTypes. To ensure conformance, UBL is limited to using this approved set. Link to Profile Customization is a key aspect of UBL’s reusability across business verticals. The UBL rules have been developed in recognition of the need to support customizations. Specific UBL customization rules are detailed in the UBL customization guidelines.

UBL documents are designed to effect data-centric electronic commerce. Including mixed content in business documents is undesirable because business transactions are based on exchange of discrete pieces of data that must be clearly unambiguous. The white space aspects of mixed content make processing unnecessarily difficult and add a layer of complexity not desirable in business exchanges. Link to Profile

The effective management of the UBL library requires that all element declarations are unique across the breadth of the UBL library. Consequently, UBL elements are declared globally.

UBL elements are global and qualified. Hence in the example below, the <Address> element is directly reusable as a modular component and some software can be used without modification. Example Software written to work with UBL's standard library will work with new assemblies of the same components since global elements will remain consistent and unchanged. The globally declared <Address> element is fully reusable without regard to the reusability of types and provides a solid mechanism for ensuring that extensions to the UBL core library will provide consistency and semantic clarity regardless of its placement within a particular type. Link to Profile

There is a recognized requirement that some organizations are required by law to send additional information not covered by the UBL document structure, thus requiring an extension to the UBL message. The xsd:any construct is seen as the most efficient way to implement this requirement. In general, UBL restricts the use of xsd:any because this feature permits the introduction of potentially unknown elements into an XML instance. However, limiting its use to a single, predefined element mitigates this risk. Since it is a priority that there can be meaningful validation of the UBL document instances the value of the xsd:processContents attribute of the element must be set to “skip”, thereby removing the potential for errors in the validation layer. There is cardinality restriction in the case of extension. Link to Profile The following rules apply in the order below. Link to Profile Link to Profile Link to Profile

The concept of XML namespaces is defined in the W3C XML namespaces technical specification. Tim Bray, D Hollander, A Layman, R Tobin; Namespaces in XML 1.1, W3C Recommendation, February 2004. The use of XML namespace is specified in the W3C XML Schema (XSD) Recommendation. A namespace is declared in the root element of a Schema using a namespace identifier. Namespace declarations can also identify an associated prefix—shorthand identifier—that allows for compression of the namespace name. For each UBL namespace, a normative token is defined as its prefix. These tokens are defined in the versioning scheme section.

Neither XML 1.0 nor XSD require the use of Namespaces. However the use of namespaces is essential to managing the complex UBL library. UBL will use UBL-defined schemas (created by UBL) and UBL-used schemas (created by external activities) and both require a consistent approach to namespace declarations. Link to Profile Each UBL schema module consists of a logical grouping of lower level artifacts that together comprise an association that will be able to be used in a variety of UBL schemas. These schema modules are grouped into a schema set. Each schema set is assigned a namespace that identifies that group of schema modules. As constructs are changed, new versions will be created. The schema set is the versioned entity, all schema modules within that package are of the same version, and each version has a unique namespace. [Definition] Schema Set – A collection of schema instances that together comprise the names in a specific UBL namespace. Schema validation ensures that an instance conforms to its declared schema. There should never be two (different) schemas with the same namespace Uniform Resource Identifier (URI). In keeping with Rule NMS1, each UBL schema module will be part of a versioned namespace. Link to Profile UBL’s extension methodology encourages a wide variety in the number of schema modules that are created as derivations from UBL schema modules. Clarity and consistency requires that customized schema not be confused with those developed by UBL. Link to Profile

A UBL namespace name must be a URI reference that conforms to RFC 2396. T. Berners-Lee, R. Fielding, L. Masinter; Internet Engineering Task Force (IETF) RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, Internet Society, August 1998. UBLhas adopted the Uniform Resource Name (URN) scheme as the standard for URIs for UBLnamespaces, in conformance with IETF’s RFC 3121, as defined in this next section. Karl Best, N. Walsh,; Internet Engineering Task Force (IETF) RFC 3121, A URN Namespace for OASIS, June 2001. Rule NMS2 requires separate namespaces for each UBL schema set. The UBL namespace rules differentiate between committee draft and OASIS Standard status. For each schema holding draft status, a UBL namespace must be declared and named. Link to Profile urn:oasis:names:tc:ubl:schema:<subtype>:<document-id> The format for document-id is found in the next section. For each UBL schema holding OASIS Standard status, a UBL namespace must be declared and named using the same notation, but with the value ‘specification” replacing the value ‘tc’. Link to Profile

UBL schemas use a URN namespace scheme. In contrast, schema locations are typically defined as a Uniform Resource Locator (URL). UBL schemas must be available both at design time and run time. As such, the UBL schema locations will differ from the UBL namespace declarations. UBL, as an OASIS TC, will utilize an OASIS URL for hosting UBL schemas. UBL will use the committee directory http://www.oasis-open.org/committees/ubl/schema/.

A key differentiator in selecting URNs to define UBL namespaces is URN persistence. UBL namespaces must never violate this functionality by subsequently changing once it has been declared. Conversely, changes to a schema may result in a new namespace declaration. Thus a published schema version and its namespace association will always be inviolate. Link to Profile

UBL has adopted a two-layer versioning scheme. Major version information is captured within the namespace name of each UBL schema module while combined major and minor version information is captured within the xsd:version attribute of the xsd:schema element. UBL namespaces conform to the OASIS namespace rules defined in RFC 3121. Karl Best, N. Walsh; Internet Engineering Task Force (IETF) RFC 3121, A URN Namespace for OASIS, June 2001. The last field of the namespace name is called document-id. UBL has decided to include versioning information as part of the document-id component of the namespace. Only major version information will be captured within the document-id. The major field has an optional revision extension which can be used for draft schemas. For example, the namespace URI for the draft Invoice domain has this form: urn:oasis:names:tc:ubl:schema:xsd:Invoice-<major>[.<revision>] The major-version field is “1” for the first release of a namespace. Subsequent major releases increment the value by 1. For example, the first namespace URI for the first major release of the Invoice document has the form: urn:oasis:names:tc:ubl:schema:xsd:Invoice-1 The second major release will have a URI of the form: urn:oasis:names:tc:ubl:schema:xsd:Invoice-2 In general, the namespace URI for every major release of the Invoice domain has the form: urn:oasis:names:tc:ubl:schema:xsd:Invoice:-<major-number>[.<revision>] Link to Profile Link to Profile Link to Profile Link to Profile Link to Profile <name>-<major> Link to Profile <major>.0 For each document produced by the TC, the TC will determine the value of the <name> variable. In UBL, the major-version field must be changed in a release that breaks compatibility with the previous release of that namespace. If a change does not break compatibility then only the minor version need change. Subsequent minor releases begin with minor-version 1. Example The namespace URI for the first minor release of the Invoice domain has this form: urn:oasis:names:tc:ubl:schema:xsd:Invoice-<major> The value of the xsd:schema xsd:version attribute for the first minor release of the Invoice domain has this form: <major>.1 Link to Profile Link to Profile Link to Profile Link to Profile Link to Profile <name>-<major> Link to Profile <major>.<non-zero> Once a schema version is assigned a namespace, that schema version and that namespace will be associated in perpetuity. However, because minor schema versions will retain the major version namespace, this is not a one-to-one relationship. Link to Profile UBL is composed of a number of interdependent namespaces. For instance, namespaces whose URI’s start with urn:oasis:names:tc:ubl:schema:xsd:Invoice-* are dependent upon the common basic and aggregate namespaces, whose URI’s have the form urn:oasis:names:tc:ubl:schema:xsd:CommonBasicComponents-* and urn:oasis:names:tc:ubl:schema:xsd:CommonAggregateComponents-* respectively. If either of the common namespaces requires a major version change then its namespace URI must change. If its namespace URI changes then any schema that imports the new version of the namespace must also change (to update the namespace declaration). And since this would require a major version change to the importing schema, its namespace URI in turn must change. The outcome is twofold: There should never be ambiguity at the point of reference in a namespace declaration or version identification. A dependent schema imports precisely the version of the namespace that is needed. The dependent schema never needs to account for the possibility that the imported namespace can change. When a dependent schema is upgraded to import a new version of a schema, the dependent schema’s version must change. Minor version changes, however, would not require changes to the namespace URI of any schemas. Version numbers are based on a logical progression. All major and minor version numbers will be based on positive integers. Version numbers always increment positively by one. Link to Profile Link to Profile UBL version information will also be captured in instances of UBL document schemas via a ubl:UBLVersion element. Link to Profile A minor revision (of a schema) imports the schema module for the previous version. For instance, the schema module defining xsd:version = “1.2” will import the schema defining xsd:version = “1.1” The version 1.2 revision may define new complex types by extending version 1.1 types. It may define brand new complex types and elements by composition. It may also use the XSD redefine element to change the definition of a type or element in the 1.1 version as long as it only redefines via the xsd:extension mechanism. For a particular namespace, the minor versions of a major version form a linearly-linked family. The first minor version schema imports its parent major version schema. Each successive minor version schema imports the schema module of the preceding minor version. Example The minor version schema module defining xsd:version = “1.2” will import the minor version schema defining xsd:version = “1.1” which will, in turn, import the major version schema defining xsd:version = “1.0”. Each of these schemas will have the namespace name that is declared in the major version 1.0 schema. Link to Profile To ensure that backwards compatibility through polymorphic processing of minor versions within a major version always occurs, minor versions must be limited to certain allowed changes. This guarantee of backward compatibility is built into the xsd:extension mechanism. Thus, backward incompatible version changes can not be expressed using this mechanism. Link to Profile In addition to polymorphic processing considerations, semantic compatibility across minor versions (as well as major versions) is essential. Semantic compatibility in this sense pertains to preserving the business function. This does not preclude the deprecation of a particular syntactic construct, and its replacement by a completely new syntactic construct with a new name. Link to Profile

There are many possible mappings of XML schema constructs to namespaces and to files. In addition to the logical taming of complexity that namespaces provide, dividing the physical realization of schema into multiple files—schema modules—provides a mechanism whereby reusable components can be imported as needed without the need to import overly complex complete schema. Link to Profile [Definition] schema module – A schema document containing type definitions and element declarations intended to be reused in multiple schemas.

UBL relies extensively on modularity in schema design. There is no single UBL root schema. Rather, there are a number of UBL document schemas, each of which expresses a separate business function. The UBL modularity approach is structured so that users can reuse individual document schemas without having to import the entire UBL document schema library. Additionally, a document schema can import individual modules without having to import all UBL schema modules. Each document schema will define its own dependencies. The UBL schema modularity model ensures that logical associations exist between document and internal schema modules and that individual modules can be reused to the maximum extent possible. This is accomplished through the use of document and internal schema modules as shown in Figure 3-1. If the contents of a namespace are small enough then they can be completely specified within a single schema. Figure 3-1. UBL Schema Modularity Model Figure 3-1 shows the one-to-one correspondence between document schemas and namespaces. It also shows the one-to-one correspondence between files and schema modules. As shown in figure 3-1, there are two types of schema in the UBL library – document schema and schema modules. Document schemas are always in their own namespace. Schema modules may be in a document schema namespace as in the case of internal schema modules, or in a separate namespace as in the ubl:qdt, ubl:cbc, ubl:cac, ubl:cl, and ubl:ccts schema modules. Both types of schema modules are conformant with W3C XSD. A namespace is a collection of semantically related elements, types and attributes. For larger namespaces, schema modules – internal schema modules – may be defined. UBL document schemas may have zero or more internal modules that they include. The document schema for a namespace then includes those internal modules. [Definition] Internal schema module – A schema that is part of a schema set within a specific namespace. Figure 3-2 Schema Modules Another way to visualize the structure is by example. Figure 3-2 depicts instances of the various schema modules from the previous diagram. Figure 3-3 Order and Invoice Schema Import of Common Component Schema Modules Figure 3-3 shows how the order and invoice document schemas import the "CommonAggregateComponents Schema Module” and “CommonBasicComponents Schema Module” external schema modules. It also shows how the order document schema includes various internal modules – modules local to that namespace. The clear boxes show how the various schema modules are grouped into namespaces. Any UBL schema module, be it a document schema or an internal module, may import other document schemas from other namespaces.

If two namespaces are mutually dependent then clearly, importing one will cause the other to be imported as well. For this reason there must not exist circular dependencies between UBL schema modules. By extension, there must not exist circular dependencies between namespaces. A namespace “A” dependent upon type definitions or element declaration defined in another namespace “B” must import “B’s” document schema. Link to Profile To ensure there is no ambiguity in understanding this rule, an additional rule is necessary to address potentially circular dependencies as well – schema A must not import internal schema modules of schema B. Link to Profile

UBL has defined a set of naming and design rules that are carefully crafted to ensure maximum interoperability and standardization. Link to Profile

UBL will create schema modules which, as illustrated in Figure 3-1 and Figure 3-2, will either be located in the same namespace as the corresponding document schema, or in a separate namespace. Link to Profile

UBL internal schema modules do not declare a target namespace, but instead reside in the namespace of their parent schema. All internal schema modules will be accessed using xsd:include. Link to Profile UBL internal schema modules will necessarily have semantically meaningful names. Internal schema module names will identify the parent schema module, the internal schema module function, and the schema module itself. Link to Profile

UBL is dedicated to maximizing reuse. As the complex types and global element declarations will be reused in multiple UBL schemas, a logical modularity approach is to create UBL schema modules based on collections of reusable types and elements. Link to Profile As identified in rule SSM2, UBL will create external schema modules. These external schema modules will be based on logical groupings of contents. At a minimum, UBL schema modules will be comprised of: UBL CommonAggregateComponents UBL CommonBasicComponents UBL Code List(s) UBL Qualified Datatypes CCTS Core Component Parameters (Used as a reference only.) In addition UBL will use the following schema modules provided by UN/CEFACT. CCTS Core Component Types CCTS Unqualified Datatypes UN/CEFACT Code Lists Furthermore, where extensions are used an extension schema module must be provided. This schema module must be named: CommonExtensionComponents This schema module must not import UBL-defined external schema modules. Link to Profile

The UBL library will also contain a wide variety of ccts:AggregateBusinessInformationEntities. As defined in rule CTD1, each of these ccts:AggregateBusinessInformationEntity classes will be defined as an xsd:complexType. Although some of these complex types may be used on only one UBL Schema, many will be reused in multiple UBL schema modules. An aggregation of all of the ccts:AggregateBusinessInformationEntity xsd:complexType definitions that are used in multiple UBL schema modules into a single schema module of common aggregate types will provide for maximum ease of reuse. Link to Profile The normative name for this xsd:ComplexType schema module will be based on its ccts:AggregateBusinessInformationEntity content. Link to Profile Example Document Name: CommonAggregateComponents

In keeping with the overall UBL namespace approach, a singular namespace must be created for storing the ubl:CommonAggregateComponents schema module. Link to Profile To ensure consistency in expressing this module, a normative token that will be used consistently in all UBL Schemas must be defined. Link to Profile

The UBL library will contain a wide variety of ccts:BasicBusinessInformationEntities. These ccts:BasicBusinessInformationEntities are based on ccts:BasicBusinessInformationEntityProperties. BBIE properties are reusable in multiple BBIEs. As defined in rule CTD25, each of these ccts:BasicBusinessInformationEntityProperties is defined as an xsd:complexType. Although some of these complex types may be used in only one UBL Schema, many will be reused in multiple UBL schema modules. To maximize reuse and standardization, all of the ccts:BasicBusinessInformationEntityProperty xsd:ComplexType definitions that are used in multiple UBL schema modules will be aggregated into a single schema module of common basic types. Link to Profile The normative name for this schema module will be based on its ccts:BasicBusinessInformationEntityProperty xsd:ComplexType content. Link to Profile

In keeping with the overall UBL namespace approach, a singular namespace must be created for storing the ubl:CommonBasicComponents schema module. Link to Profile To ensure consistency in expressing the ubl:CommonBasicComponents schema module, a normative token that will be used consistently in all UBL Schema must be defined. Link to Profile

The CCTS defines an authorized set of Core Component Types (ccts:CoreComponentTypes) that convey content and supplementary information related to exchanged data. As the basis for all higher level CCTS models, the ccts:CoreComponentTypes are reusable in every UBL schema. An external schema module consisting of a complex type definition for each ccts:CoreComponentType is essential to maximize reusability. UBL uses the ccts:CoreComponentType schema module provided by UN/CEFACT.

The CCTS defines an authorized set of primary and secondary Representation Terms (ccts:RepresentationTerms) that describes the form of every ccts:BusinessInformationEntity. These ccts:RepresentationTerms are instantiated in the form of datatypes that are reusable in every UBL schema. The ccts:Datatype defines the set of valid values that can be used for its associated ccts:BasicBusinessInformationEntity Property. These datatypes may be qualified or unqualified, that is to say restricted or unrestricted. We refer to these as ccts:UnqualifiedDatatypes (even though they are technically ccts:Datatypes)or ubl:QualifiedDatatypes.

UBL has adopted the UN/CEFACT Unqualified Datatype schema module.This includes the four code list schema modules that are imported into this schema module. When the ccts:UnqualifiedDatatypes schema module is referenced the “udt” namespace prefix must be used. Link to Profile

The ubl:QualifiedDatatype is defined by specifying restrictions on the ccts:UnqualifiedDatatype. To ensure the consistency of UBL qualified Datatypes (ubl:QualifiedDatatypes) with the UBL modularity and reuse goals requires creating a single schema module that defines all ubl:QualifiedDatatypes. Link to Profile The ubl:QualifiedDatatypes must be based upon the ccts:UnqualifiedDatypes. Link to Profile The ubl:QualifiedDatatypes schema module name must follow the UBL module naming approach. Link to Profile

In keeping with the overall UBL namespace approach, a singular namespace must be created for storing the ubl:QualifiedDatatypes schema module. Link to Profile To ensure consistency in expressing the ubl:QualifiedDatatypes schema module, a normative token that will be used in all UBL schemas must be defined. Link to Profile To ensure consistency in expressing the CommonExtensionComponent schema moduel, a normative token that will be used in all UBL schemas must be defined. Link to Profile

Annotation is an essential tool in understanding and reusing a schema. UBL, as an implementation of CCTS, requires an extensive amount of annotation to provide all necessary metadata required by the CCTS specification. Each construct declared or defined within the UBL library contains the requisite associated metadata to fully describe its nature and support the CCTS requirement. Accordingly, UBL schema metadata for each construct will be defined in the CCTS core component parameters schema.

Although the UBL schema annotation is necessary, its volume results in a considerable increase in the size of the UBL schemas with undesirable performance impacts. To address this issue, two normative schema will be developed for each UBL schema. A fully annotated schema will be provided to facilitate greater understanding of the schema module and its components, and to meet the CCTS metadata requirements. A schema devoid of annotation will also be provided that can be used at run-time if required to meet processor resource constraints. Link to Profile

The information about each UBL ccts:BusinessInformationEntity is in the UBL spreadsheet models. UBL spreadsheets contain all necessary information to produce fully annotated Schemas. Fully annotated Schemas are valuable tools to implementers to assist in understanding the nuances of the information contained therein. UBL annotations will consist of information currently required by Section 7 of the CCTS and supplemented by metadata from the UBL spreadsheet models. The absence of an optional annotation inside the structured set of annotations in the documentation element implies the use of the default value. For example, there are several annotations relating to context such as ccts:BusinessContext or ccts:IndustryContext whose absence implies that their value is "all contexts". The following rules describe the documentation requirements for each ubl:QualifiedDatatype and ccts:UnqualifiedDatatype definition. Consequently, none of these documentation rules apply in the case of extension where the 'UBL Extensions' element is used. Link to Profile • DictionaryEntryName (mandatory) • Version (mandatory): • Definition(mandatory) • RepresentationTerm (mandatory) • QualifierTerm(s) (mandatory, where used) • UniqueIdentifier (mandatory) • Usage Rule(s) (optional) • Content Component Restriction (optional) Link to Profile • RestrictionType (mandatory): Defines the type of format restriction that applies to the Content Component. • RestrictionValue (mandatory): The actual value of the format restriction that applies to the Content Component. • ExpressionType (optional): Defines the type of the regular expression of the restriction value. Link to Profile • SupplementaryComponentName (mandatory): Identifies the Supplementary Component on which the restriction applies. • RestrictionValue (mandatory, repetitive): The actual value(s) that is (are) valid for the Supplementary Component The following rule describes the documentation requirements for each ccts:BasicBusinessInformationEntity definition. Link to Profile • ComponentType (mandatory): The type of component to which the object belongs. For Basic Business Information Entities this must be “BBIE”. • DictionaryEntryName (mandatory): The official name of a Basic Business Information Entity. • Version (optional): An indication of the evolution over time of the Basic Business Information Entity. • Definition(mandatory): The semantic meaning of a Basic Business Information Entity. • Cardinality(mandatory): Indication whether the Basic Business Information Entity represents a not-applicable, optional, mandatory and/or repetitive characteristic of the Aggregate Business Information Entity. • ObjectClassQualifier (optional): The qualifier for the object class. • ObjectClass(mandatory): The Object Class containing the Basic Business Information Entity. • PropertyTermQualifier (optional): A qualifier is a word or words which help define and differentiate a Basic Business Information Entity. • PropertyTerm(mandatory): Property Term represents the distinguishing characteristic or Property of the Object Class and shall occur naturally in the definition of the Basic Business Information Entity. • RepresentationTerm (mandatory): A Representation Term describes the form in which the Basic Business Information Entity is represented. • DataTypeQualifier (optional): semantically meaningful name that differentiates the Datatype of the Basic Business Information Entity from its underlying Core Component Type. • DataType (mandatory): Defines the Datatype used for the Basic Business Information Entity. • AlternativeBusinessTerms (optional): Any synonym terms under which the Basic Business Information Entity is commonly known and used in the business. • Examples (optional): Examples of possible values for the Basic Business Information Entity. The following rule describes the documentation requirements for each ccts:AggregateBusinessInformationEntity definition. Link to Profile • ComponentType (mandatory): The type of component to which the object belongs. For Aggregate Business Information Entities this must be “ABIE”. • DictionaryEntryName (mandatory): The official name of the Aggregate Business Information Entity . • Version (optional): An indication of the evolution over time of the Aggregate Business Information Entity. • Definition(mandatory): The semantic meaning of the Aggregate Business Information Entity. • ObjectClassQualifier (optional): The qualifier for the object class. • ObjectClass(mandatory): The Object Class represented by the Aggregate Business Information Entity. • AlternativeBusinessTerms (optional): Any synonym terms under which the Aggregate Business Information Entity is commonly known and used in the business. The following rule describes the documentation requirements for each ccts:AssociationBusinessInformationEntity definition. Link to Profile • ComponentType (mandatory): The type of component to which the object belongs. For Association Business Information Entities this must be “ASBIE”. • DictionaryEntryName (mandatory): The official name of the Association Business Information Entity. • Version (optional): An indication of the evolution over time of the Association Business Information Entity. • Definition(mandatory): The semantic meaning of the Association Business Information Entity. • Cardinality(mandatory): Indication whether the Association Business Information Entity represents an optional, mandatory and/or repetitive assocation. • ObjectClass(mandatory): The Object Class containing the Association Business Information Entity. • PropertyTermQualifier (optional): A qualifier is a word or words which help define and differentiate the Association Business Information Entity. • PropertyTerm(mandatory): Property Term represents the Aggregate Business Information Entity contained by the Association Business Information Entity. • AssociatedObjectClassQualifier (optional): Associated Object Class Qualifiers describe the 'context' of the relationship with another ABIE. That is, it is the role the contained Aggregate Business Information Entity plays within its association with the containing Aggregate Business Information Entity. • AssociatedObjectClass (mandatory); Associated Object Class is the Object Class at the other end of this association. It represents the Aggregate Business Information Entity contained by the Association Business Information Entity. Link to Profile • Name (mandatory): Name in the Registry of a Supplementary Component of a Core Component Type. • Definition (mandatory): A clear, unambiguous and complete explanation of the meaning of a Supplementary Component and its relevance for the related Core Component Type. • Primitive type (mandatory): PrimitiveType to be used for the representation of the value of a Supplementary Component. • Possible Value(s) (optional): one possible value of a Supplementary Component. Link to Profile • Restriction Value(s) (mandatory): The actual value(s) that is (are) valid for the Supplementary Component.

The rules in this section make use of the following special concepts related to XML elements. Top-level element: An element that encloses a whole UBL business message. Note that UBL business messages might be carried by messaging transport protocols that themselves have higher-level XML structure. Thus, a UBL top-level element is not necessarily the root element of the XML document that carries it. Lower-level element: An element that appears inside a UBL business message. Lower-level elements consist of intermediate and leaf level. Intermediate element: An element not at the top level that is of a complex type, only containing other elements and attributes. Leaf element: An element containing only character data (though it may also have attributes). Note that, because of the XSD mechanisms involved, a leaf element that has attributes must be declared as having a complex type, but a leaf element with no attributes may be declared with either a simple type or a complex type.

The CCTS contains specific Internal Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) Technical Specification 11179 Information technology– -- Metadata registries (MDR) based naming rules for each CCTS construct. The UBL component library, as a syntax-neutral representation, is fully conformant to those rules. The UBL syntax-specific XSD instantiation of the UBL component library—in some cases—refines the CCTS naming rules to leverage the capabilities of XML and XSD. Specifically, truncation rules are applied to allow for reuse of element names across parent element environments and to maintain brevity and clarity. In keeping with CCTS, UBL will use English as its normative language. If the UBL Library is translated into other languages for localization purposes, these additional languages might require additional restrictions. Such restrictions are expected be formulated as additional rules and published as appropriate. Link to Profile UBL fully supports the concepts of data standardization contained in ISO 11179. CCTS, as an implementation of 11179, furthers its basic tenets of data standardization into higher-level constructs as expressed by the ccts:DictionaryEntryNames of those constructs – such as those for ccts:BasicBusinessInformationEntities and ccts:AggregateBusinessInformationEntities. Since UBL is an implementation of CCTS, UBL uses CCTS dictionary entry names as the basis for UBL XML schema construct names. UBL converts these ccts:DictionaryEntryNames into UBL XML schema construct names using strict transformation rules. Link to Profile The ISO 11179 specifies—and the CCTS uses—periods, spaces, other separators, and characters not allowed by W3C XML. These separators and characters are not appropriate for UBL XML component names. Link to Profile Acronyms and abbreviations impact on semantic interoperability, and as such are to be avoided to the maximum extent practicable. Since some abbreviations will inevitably be necessary, UBL will maintain a normative list of authorized acronyms and abbreviations. Appendix B provides the current list of permissible acronyms, abbreviations and word truncations. The intent of this restriction is to facilitate the use of common semantics and greater understanding. Appendix B is a living document and will be updated to reflect growing requirements. Link to Profile UBL does not desire a proliferation of acronyms and abbreviations. Appendix B is an exception list and will be tightly controlled by UBL. Any additions will only occur after careful scrutiny to include assurance that any addition is critically necessary, and that any addition will not in any way create semantic ambiguity. Link to Profile Once an acronym or abbreviation has been approved, it is essential to ensuring semantic clarity and interoperability that the acronym or abbreviation is always used. Link to Profile Generally speaking, the names for UBL XML constructs must always be singular. The only exception permissible is where the concept itself is pluralized. Link to Profile Example: Terms Link to Profile Link to Profile XML is case sensitive. Consistency in the use of case for a specific XML component (element, type) is essential to ensure every occurrence of a component is treated as the same. This is especially true in a business-based data-centric environment such as what is being addressed by UBL. Additionally, the use of visualization mechanisms such as capitalization techniques assist in ease of readability and ensure consistency in application and semantic clarity. The ebXML architecture document specifies a standard use of upper and lower camel case for expressing XML elements and attributes respectively. ebXML, ebXML Technical Architecture Specification v1.0.4, 16 February 2001 UBL will adhere to the ebXML standard. Specifically, UBL element and type names will be in UpperCamelCase (UCC). Link to Profile CurrencyBaseRate CityNameType

UBL identifies several categories of naming rules for types, namely for complex types based on Aggregate Business Information Entities, Basic Business Information Entities, Primary Representation Terms, Secondary Representation Terms and the Core Component Types. Each of these CCTS constructs have a ccts:DictionaryEntryName that is a fully qualified construct based on ISO 11179. As such, these names convey explicit semantic clarity with respect to the data being described. Accordingly, these ccts:DictionaryEntryNames provide a mechanism for ensuring that UBL xsd:complexType names are semantically unambiguous, and that there are no duplications of UBL type names for different xsd:type constructs.

UBL xsd:complexType names for ccts:AggregateBusinessInformationEntities will be derived from their dictionary entry name by removing separators to follow general naming rules, and appending the suffix “Type” to replace the word “Details.” Link to Profile Example: ccts:AggregateBusiness InformationEntity UBL xsd:complexType Address. Details AddressType Financial Account. Details FinancialAccountType

All ccts:BasicBusinessInformationEntityProperties are reusable across multiple ccts:BasicBusinessInformationEntities. The CCTS does not specify, but implies, that ccts:BasicBusinessInformationEntityProperty names are the reusable property term and representation term of the family of ccts:BasicBusinessInformationEntities that are based on it. The UBL xsd:complexType names for ccts:BasicBusinessInformationEntity properties will be derived from the shared property and representation terms portion of the dictionary entry names in which they appear by removing separators to follow general naming rules, and appending the suffix “Type”. Link to Profile Example: Link to Profile Link to Profile Link to Profile

As defined in the UBL Model (See Figure 2-3), UBL elements will be created for ccts:AggregateBusinessInformationEntities, ccts:BasicBusinessInformationEntities, and ccts:AssociationBusinessInformationEntities. UBL element names will reflect this relationship in full conformance with ISO11179 element naming rules.

Link to Profile Example: For a ccts:AggregateBusinessInformationEntity of Party.Details, Rule CTN1 states that the Party.Details object class becomes PartyType xsd:ComplexType. Rule ELD3 states that for the PartyType xsd:complexType, a corresponding global element must be declared. Rule ELN1 states that the name of this corresponding global element must be Party.

The same naming concept used for ccts:AggregateBusinessInformationEntities applies to ccts:BasicBusinessInformationEntityProperty. Link to Profile Example:

A ccts:AssociationBusinessInformationEntity is not a class like ccts:AggregateBusinessInformationEntities and like ccts:BasicBusinessInformationEntityProperties that are reused as ccts:BasicBusinessInformationEntities. Rather, it is an association between two classes. As such, an element representing the ccts:AssociationBusinessInformationEntity does not have its own unique xsd:ComplexType. Instead, when an element representing a ccts:AssociationBusinessInformationEntity is declared, the element is bound to the xsd:complexType of its associated ccts:AggregateBusinessInformationEntity by referencing its global element declaration. Link to Profile [

UBL, as a transactional based XML exchange format, has chosen to significantly restrict the use of attributes. This restriction is in keeping with the fact that attribute usage is relegated to supplementary components only; all “primary” business data appears exclusively in element content. These attributes are defined in the UN/CEFACT Unqualified Datatype schema module,

In W3C XML Schema, elements are defined in terms of complex or simple types and attributes are defined in terms of simple types. The rules in this section govern the consistent structuring of these type constructs and the manner for unambiguously and thoroughly documenting them in the UBL Library.

Since UBL elements and types are intended to be reusable, all types must be named. This permits other types to establish elements that reference these types, and also supports the use of extensions for the purposes of versioning and customization. Link to Profile Example: UBL disallows the use of xsd:anyType, because this feature permits the introduction of potentially unknown types into an XML instance. UBL intends that all constructs within the instance be described by the schemas describing that instance - xsd:anyType is seen as working counter to the requirements of interoperability. In consequence, particular attention is given to the need to enable meaningful validation of the UBL document instances. Were it not for this, xsd:anyType might have been allowed. Link to Profile

The Core Components Technical Specification provides a set of constructs for the modeling of basic data, Core Component Types. These are represented in UBL with a library of complex types, with the effect that most "simple" data is represented as property sets defined according to the CCTs, made up of content components and supplementary components. In most cases, the supplementary components are expressed as XML attributes, the content component becomes element content, and the CCT is represented with an xsd:complexType. There are exceptions to this rule in those cases where all of a CCT's properties can be expressed without the use of attributes. In these cases, an xsd:simpleType is used. UBL does not define its own simple types. These are defined in the UN/CEFACT Unqualified Datatype schema module. UBL may define restrictions of these simple types in the UBL Qualified datatype schema module.

Since even simple datatypes are modeled as property sets in most cases, the XML expression of these models primarily employs xsd:complexType. To facilitate reuse, versioning, and customization, all complex types are named. In the UBL model, ccts:AggregateBusinessInformationEntities are considered classes(objects) . Link to Profile Example: Every class identified in the UBL model consists of properties. These properties are either ASBIEs, when the property represents another class, or BBIE properties. Link to Profile

The relationship expressed by an Aggregate Business Information Entity is not directly represented with a class. Instead, this relationship is captured in UBL with a containment relationship, expressed in the content model of the parent object’s type with a sequence of elements. (Sequence facilitates the use of xsd:extension for versioning and customization.) The members of the sequence – elements which are themselves defined by reference to complex types – are the properties of the containing type. Link to Profile Example:

All ccts:BasicBusinessInformationEntities, in accordance with the Core Components Technical Specification, always have a representation term. This may be a primary or secondary representation term. Representation terms describe the structural representation of the BBIE. These representation terms are expressed in the UBL Model as Unqualified Datatypes bound to a Core Component Type that describes their structure. In addition to the Unqualified Datatypes defined in CCTS, UBL has defined a set of Qualified Datatypes that are derived from the CCTS Unqualified Datatypes.There are a set of rules concerning the way these relationships are expressed in the UBL XML library. As discussed above, ccts:BasicBusinessInformationEntityProperties are represented with complex types. Within these are simpleContent elements that extend the Datatypes. Link to Profile Link to Profile Link to Profile Example:

There is a direct one-to-one relationship between ccts:CoreComponentTypes and ccts:PrimaryRepresentationTerms. Additionally, there are several ccts:SecondaryRepresentationTerms that are semantic refinements of their parent ccts:PrimaryRepresentationTerm. The total set of ccts:RepresentationTerms by their nature represent ccts:Datatypes. Specifically, for each ccts:PrimaryRepresentationTerm or ccts:SecondaryRepresentationTerm, a ccts:UnqualifiedDatatype exists. In the UBL XML Library, these ccts:UnqualifiedDatatypes are expressed as complex or simple types that are of the type of its corresponding ccts:CoreComponentType. UBL uses the ccts:UnqualifiedDatatypes that are provided by the UN/CEFACT Unqualified Datatype (udt) schema module.

The data types defined in the unqualified data type schema module are intended to be suitable as the xsd:base type for some, but not all BBIEs. As business process modeling reveals the need for specialized data types, new ‘qualified’ types will need to be defined. These new ccts:QualifiedDatatype must be based on an ccts:UnqualifiedDatatype and must represent a semantic or technical restriction of the ccts:UnqualifiedDatatype. Technical restrictions must be implemented as a xsd:restriction or as a new xsd:simpleType if the supplementary components of the qualified data type map directly to the properties of a built-in XSD data type. Link to Profile Link to Profile Link to Profile In accordance with rule GXS3 built-in XSD data types will be used whenever possible. Link to Profile MUST be defined as an xsd:simpleType MUST contain one xsd:restriction element MUST include an xsd:base attribute that defines the specific XSD built-in data type required for the content component Link to Profile MUST be defined as an xsd:complexType MUST contain one xsd:simpleContent element MUST contain one xsd:restriction element MUST include the unqualified datatype as its xsd:base attribute Link to Profile MUST contain one xsd:restriction element MUST include the unqualified datatype as its xsd:base attribute

The binding of UBL elements to their xsd:complexType is based on the associations identified in the UBL model. For the ccts:BasicBusinessInformationEntities and ccts:AggregateInformationEntities, the UBL elements will be directly associated to its corresponding xsd:complexType. Link to Profile Example: For the Party.Details object class, a complex type/global element declaration pair is created through the declaration of a Party element that is of type PartyType. The element thus created is useful for reuse in the building of new business messages. The complex type thus created is useful for both reuse and customization, in the building of both new and contextualized business messages. Example:

A ccts:AssociationBusinessInformationEntity is not a class like ccts:AggregateBusinessInformationEntities. Rather, it is an association between two classes. As such, the element declaration will bind the element to the xsd:complexType of the associated ccts:AggregateBusinessInformationEntity. There are two types of ASBIEs – those that have qualifiers in the object class, and those that do not. Link to Profile Link to Profile

Link to Profile

Link to Profile

UBL has determined that the best approach for code lists is to handle them as schema modules. In recognition of the fact that most code lists are maintained by external agencies, UBL has determined that if code list owners all used the same normative form schema module, all users of those code lists could avoid a significant level of code list maintenance. By having each code list owner develop, maintain, and make available via the internet their code lists using the same normative form schema, code list users would be spared the unnecessary and duplicative efforts required for incorporation in the form of enumeration of such code lists into Schema, and would subsequently avoid the maintenance of such enumerations since code lists are handled as imported schema modules rather than cumbersome enumerations. To make this mechanism operational, UBL has defined a number of rules. To avoid enumeration of codes in the document or reusable schemas, UBL has determined that codes will be handled in their own schema modules. Link to Profile Because the majority of code lists are owned and maintained by external agencies, UBL will make maximum use of such external code lists where they exist. Link to Profile In some cases the UBL Library may extend an existing code list to meet specific business requirements. In others cases the UBL Library may have to create and maintain a code list where a suitable code list does not exist in the public domain. Both of these types of code lists would be considered UBL-internal code lists. Link to Profile UBL-internal code lists will be designed with maximum re-use in mind to facilitate maximum use by others. If a UBL code list is created, the lists should be globally scoped (designed for reuse and sharing, using named types and namespaced Schema Modules) rather than locally scoped (not designed for others to use and therefore hidden from their use). To guarantee consistency within all code list schema modules all ubl-internal code lists and externally used code lists will use the UBL Code List Schema Module. This schema module will contain an enumeration of code list values. Link to Profile To guarantee consistency of code list schema module naming, the name of each UBL Code List Schema Module will adhere to a prescribed form. Link to Profile {Owning Organization}{Code List Name}{Code List Schema Module} Example ISO 8601 Country Code Code List Schema Module ISO 3055 Kitchen equipment–- Coordinating sizes Code Code List Schema Module Code list attribute values for UBL code lists should be set to 'default' rather than fixed. This facilitates customization and caters for instances whereby the values are not specified. Link to Profile Each UBL Code List Schema Module will import the UBL QDT Schema Module where there is defined a UBLCodeType. This type will be a trivial extension of the udt:CodeType in the ATG2 UDT schema by creating a union of the UDT code type and an enumeration — each enumeration being a restriction on the udt:CodeType. Each code list used in the UBL schema MUST be imported individually. Link to Profile The UBL library allows partial implementations of code lists which may required by customizers. Link to Profile The following rule describes the requirements for the xsd:schemaLocation for the importation of the code lists into a UBL business document. Link to Profile UBL, as a business standard vocabulary, requires consistency in its development. The number of UBL Schema developers will expand over time. To ensure consistency, it is necessary to address the optional features in XSD that are not addressed elsewhere.

UBL guiding principles require maximum reuse. XSD provides for forty four built-in Datatypes expressed as simple types. In keeping with the maximize re-use guiding principle, these built-in simple types should be used wherever possible. Link to Profile

The W3C XSD specification allows for the use of any token to represent its location. To ensure consistency, UBL has adopted the generally accepted convention of using the “xsd” token for all UBL schema and schema modules. Link to Profile xmlns:xsd="http://www.w3.org/2001/XMLSchema”

The xsd:substitutionGroup feature enables a type definition to identify substitution elements in a group. Although a useful feature in document centric XML applications, this feature is not used by UBL. Link to Profile

UBL does not use extensions in its normative schema. Extensions are allowed by customizers as outlined in the Guidelines for Customization. UBL may determine that certain type definitions are innapropriate for any customization. In those instances, the xsd:final attribute will be used. Link to Profile

The xsd:notation attribute identifies a notation. Notation declarations corresponding to all the <notation> element information items in the [children], if any, plus any included or imported declarations. Per XSD Part 2, “It is an ·error· for NOTATION to be used directly in a schema. Only Datatypes that are ·derived· from NOTATION by specifying a value for ·enumeration· can be used in a schema.” The UBL schema model does not require or support the use of this feature. Link to Profile

The xsd:all compositor requires occurrence indicators of minOccurs = 0 and maxOccurs = 1. The xsd:all compositor allows for elements to occur in any order. The result is that in an instance document, elements can occur in any order, are always optional, and never occur more than once. Such restrictions are inconsistent with data-centric scenarios such as UBL. Link to Profile

The xsd:choice compositor allows for any element declared inside it to occur in the instance document, but only one. As with the xsd:all compositor, this feature is inconsistent with business transaction exchanges. UBL recognizes that it is a very useful construct in situations where customization and extensibility are not a concern, however, UBL does not recommend its use because xsd:choice cannot be extended. Link to Profile

xsd:include can only be used when the including schema is in the same namespace as the included schema.

The xsd:union feature provides a mechanism whereby a datatype is created as a union of two or more existing datatypes. With UBL’s strict adherence to the use of ccts:Datatypes that are explicitly declared in the UBL library, this feature is inappropriate except for codelists. In some cases external customizers may choose to use this technique for codelists and as such the use of the union technique may prove beneficial for customizers. Link to Profile

The xsd:appinfo feature is used by schema to convey processing instructions to a processing application, Stylesheet, or other tool. Some users of UBL have determined that this technique poses a security risk and have employed techniques for stripping xsd:appinfo from schemas. As UBL is committed to ensuring the widest possible target audience for its XML library, this feature is not used – except to convey non-normative information. Link to Profile

UBL is an international standard that will be used in perpetuity by companies around the globe. It is important that these users have unfettered access to all UBL schema. Link to Profile

Link to Profile

UBL disallows the use of xsd:anyAttribute, because this feature permits the introduction of potentially unknown attributes into an XML instance. UBL intends that all constructs within the instance be described by the schemas describing that –instance–- xsd:anyAttribute is seen as working counter to the requirements of interoperability. In consequence, particular attention is given to the need to enable meaningful validation of the UBL document instances. Were it not for this, xsd:anyAttribute might have been allowed. Link to Profile

UBL fully recognizes the value of supporting extension and restriction of its core library by customizers. The UBL extension and restriction recommendations are discussed in the Guidelines for the Customization of UBL Schemas available as part of UBL 1.0. Link to Profile

Consistency in UBL instance documents is essential in a trade environment. UBL has defined several rules to help affect this consistency.

UBL has chosen a global element approach. Inside a UBL document schema only a single global element is declared. Because all UBL instance documents conform to a UBL document schema, the single global element declared in that document schema will be the root element of the instance. Link to Profile

The UBL library and supporting schema are targeted at supporting business information exchanges. Business information exchanges require a high degree of precision to ensure that application processing and corresponding business cycle actions are reflective of the purpose, intent, and information content agreed to by both trading partners. Schemas provide the necessary mechanism for ensuring that instance documents do in fact support these requirements. Link to Profile Link to Profile

XML supports a wide variety of character encodings. Processors must understand which character encoding is employed in each XML document. XML 1.0 supports a default value of UTF-8 for character encoding, but best practice is to always identify the character encoding being employed. Link to Profile Example: <?xml version="1.0" encoding="UTF-8"?> UBL, as an OASIS TC, is obligated to conform to agreements OASIS has entered into. OASIS is a liaison member of the ISO/IETF/ITU/UNCEFACT Memorandum of Understanding Management Group (MOUMG). Resolution 01/08 (MOU/MG01n83) requires the use of UTF-8. Link to Profile Example: <?xml version=”1.0” encoding=”UTF-8” ?>

Link to Profile xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

Usage of empty elements within XML instance documents are a source of controversy for a variety of reasons. An empty element does not simply represent data that is missing. It may express data that is not applicable for some reason, trigger the expression of an attribute, denote all possible values instead of just one, mark the end of a series of data, or appear as a result of an error in XML file generation. Conversely, missing data elements can also have meaning – data not provided by a trading partner. In information exchange environments, different trading partners may allow, require or ban empty elements. UBL has determined that empty elements do not provide the level of assurance necessary for business information exchanges and as such will not be used. Link to Profile To ensure that no attempt is made to circumvent rule IND5, UBL also prohibits attempting to convey meaning by not conveying an element. Link to Profile

The following checklist constitutes all UBL XML naming and design rules as defined in UBL Naming and Design Rules version 2.0, 26 January 2006. The checklist is in alphabetical sequence as follows: Attribute Declaration Rules (ATD) Code List Rules (CDL) ComplexType Definition Rules (CTD) ComplexType Naming Rules (CTN) Documentation Rules (DOC) Element Declaration Rules (ELD) Element Naming Rules (ELN) General Naming Rules (GNR) General Type Definition Rules (GTD) General XML Schema Rules (GXS) Instance Document Rules (IND) Modeling Constraints Rules (MDC) Naming Constraints Rules (NMC) Namespace Rules (NMS) Root Element Declaration Rules (RED) Schema Structure Modularity Rules (SSM) Standards Adherence Rules (STA) Versioning Rules (VER) Attribute Declaration rules [ATD6] (See GXS15) [ATD7] (See GXS16) [ATD8] (See GXS17) Code List rules [CDL1] All UBL Codes MUST be part of a UBL or externally maintained Code List. [CDL2] The UBL Library SHOULD identify and use external standardized code lists rather than develop its own UBL-native code lists. [CDL3] The UBL Library MAY design and use an internal code list where an existing external code list needs to be extended, or where no suitable external code list exists. [CDL4] All UBL maintained or used Code Lists MUST be enumerated using the UBL Code List Schema Module. [CDL5] The name of each UBL Code List Schema Module MUST be of the form: {Owning Organization}{Code List Name}{Code List Schema Module} [CDL6] An xsd:import element MUST be declared for every code list required in a UBL schema. [CDL7] Users of the UBL Library MAY identify any subset they wish from an identified code list for their own trading community conformance requirements. [CDL8] The xsd:schemaLocation MUST include the complete URI used to identify the relevant code list schema. [CDL9] UBL Code list attribute values SHOULD be set to 'default'. ComplexType Definition rules [CTD1] For every class and property identified in the UBL model, a named xsd:complexType MUST be defined. [CTD2] Every ccts:ABIE xsd:complexType definition content model MUST use the xsd:sequence element containing references to the appropriate global element declarations. [CTD3] Every ccts:BBIEProperty xsd:complexType definition content model MUST use the xsd:simpleContent element. [CTD4] Every ccts:BBIEProperty xsd:complexType content model xsd:simpleContent element MUST consist of an xsd:extension element. [CTD5] Every ccts:BBIEProperty xsd:complexType content model xsd:base attribute value MUST be the UN/CEFACT Unqualified Datatype or UBL qualified Datatype as appropriate. [CTD6] For every Qualified Datatype used in the UBL model, a named xsd:complexType or xsd:simpleType MUST be defined. [CTD20] A ccts:QualifiedDataType MUST be based on an unqualified data type and add some semantic and/or technical restriction to the unqualified data type. [CTD21] The name of a ccts:QualifiedDataType MUST be the name of its base ccts:UnqualifiedDataType with separators and spaces removed and with its qualifier term added. [CTD22] Every qualified datatype based on an unqualified datatype xsd:complexType whose supplementary components map directly to the properties of an XSD built-in data type MUST be defined as an xsd:simpleType MUST contain one xsd:restriction element MUST include an xsd:base attribute that defines the specific XSD built-in data type required for the content component [CTD23] Every qualified datatype based on an unqualified datatype xsd:complexType whose supplementary components do not map directly to the properties of an XSD built-in data type MUST be defined as an xsd:complexType MUST contain one xsd:simpleContent element MUST contain one xsd:restriction element MUST include the unqualified datatype as its xsd:base attribute [CTD24] Every qualified datatype based on an unqualified datatype xsd:simpleType MUST contain one xsd:restriction element MUST include the unqualified datatype as its xsd:base attribute [CTD25] For every ccts:BBIEProperty identified in the UBL model a named xsd:complexType must be defined. Complex Type Naming rules [CTN1] A UBL xsd:complexType name based on an ccts:Aggregate BusinessInformationEntity MUST be the ccts:Dictionary EntryName with the separators removed and with the “Details” suffix replaced with “Type”. [CTN2] A UBL xsd:complexType name based on a ccts:BasicBusiness InformationEntityProperty MUST be the ccts:Dictionary EntryName shared property term and its qualifiers and representation term of the ccts:BasicBusinessInformationEntity, with the separators removed and with the “Type” suffix appended after the representation term. [CTNX1] A UBL xsd:complexType name based on a ccts:BasicBusinessInformationEntityProperty and with a . ccts:BasicBusinessInformationEntityRepresentationTerm of 'Text' MUST have the word "Text" removed from the end of its name. [CTNX2] A UBL xsd:complexType name based on a ccts:BasicBusinessInformationEntityProperty and with a . ccts:BasicBusinessInformationEntityRepresentationTerm of 'Identifier' MUST have the word "Identifier" replaced by the word "ID" at the end of its name. [CTNX3] A UBL xsd:complexType name based on a ccts:BasicBusinessInformationEntityProperty MUST remove all duplication of words that occur as a result of duplicate property terms and representation terms. Documentation rules [DOC1] The xsd:documentation element for every Datatype MUST contain a structured set of annotations in the following sequence and pattern (as defined in CCTS Section 7): • DictionaryEntryName (mandatory) • Version (mandatory): • Definition(mandatory) • RepresentationTerm (mandatory) • QualifierTerm(s) (mandatory, where used) • UniqueIdentifier (mandatory) • Usage Rule(s) (optional) • Content Component Restriction (optional) [DOC2] A Datatype definition MAY contain one or more Content Component Restrictions to provide additional information on the relationship between the Datatype and its corresponding Core Component Type. If used the Content Component Restrictions must contain a structured set of annotations in the following patterns: • RestrictionType (mandatory): Defines the type of format restriction that applies to the Content Component. • RestrictionValue (mandatory): The actual value of the format restriction that applies to the Content Component. • ExpressionType (optional): Defines the type of the regular expression of the restriction value. [DOC3] A Datatype definition MAY contain one or more Supplementary Component Restrictions to provide additional information on the relationship between the Datatype and its corresponding Core Component Type. If used the Supplementary Component Restrictions must contain a structured set of annotations in the following patterns: • SupplementaryComponentName (mandatory): Identifies the Supplementary Component on which the restriction applies. • RestrictionValue (mandatory, repetitive): The actual value(s) that is (are) valid for the Supplementary Componen [DOC4] The xsd:documentation element for every Basic Business Information Entity MUST contain a structured set of annotations in the following patterns: • ComponentType (mandatory): The type of component to which the object belongs. For Basic Business Information Entities this must be “BBIE”. • DictionaryEntryName (mandatory): The official name of a Basic Business Information Entity. • Version (optional): An indication of the evolution over time of the Basic Business Information Entity. • Definition(mandatory): The semantic meaning of a Basic Business Information Entity. • Cardinality(mandatory): Indication whether the Basic Business Information Entity represents a not-applicable, optional, mandatory and/or repetitive characteristic of the Aggregate Business Information Entity. • ObjectClassQualifier (optional): The qualifier for the object class. • ObjectClass(mandatory): The Object Class containing the Basic Business Information Entity. • PropertyTermQualifier (optional): A qualifier is a word or words which help define and differentiate a Basic Business Information Entity. • PropertyTerm(mandatory): Property Term represents the distinguishing characteristic or Property of the Object Class and shall occur naturally in the definition of the Basic Business Information Entity. • RepresentationTerm (mandatory): A Representation Term describes the form in which the Basic Business Information Entity is represented. • DataTypeQualifier (optional): semantically meaningful name that differentiates the Datatype of the Basic Business Information Entity from its underlying Core Component Type. • DataType (mandatory): Defines the Datatype used for the Basic Business Information Entity. • AlternativeBusinessTerms (optional): Any synonym terms under which the Basic Business Information Entity is commonly known and used in the business. • Examples (optional): Examples of possible values for the Basic Business Information Entity [DOC5] The xsd:documentation element for every Aggregate Business Information Entity MUST contain a structured set of annotations in the following sequence and pattern: • ComponentType (mandatory): The type of component to which the object belongs. For Aggregate Business Information Entities this must be “ABIE”. • DictionaryEntryName (mandatory): The official name of the Aggregate Business Information Entity . • Version (optional): An indication of the evolution over time of the Aggregate Business Information Entity. • Definition(mandatory): The semantic meaning of the Aggregate Business Information Entity. • ObjectClassQualifier (optional): The qualifier for the object class. • ObjectClass(mandatory): The Object Class represented by the Aggregate Business Information Entity. • AlternativeBusinessTerms (optional): Any synonym terms under which the Aggregate Business Information Entity is commonly known and used in the business. [DOC6] The xsd:documentation element for every Association Business Information Entity element declaration MUST contain a structured set of annotations in the following sequence and pattern: • ComponentType (mandatory): The type of component to which the object belongs. For Association Business Information Entities this must be “ASBIE”. • DictionaryEntryName (mandatory): The official name of the Association Business Information Entity. • Version (optional): An indication of the evolution over time of the Association Business Information Entity. • Definition(mandatory): The semantic meaning of the Association Business Information Entity. • Cardinality(mandatory): Indication whether the Association Business Information Entity represents an optional, mandatory and/or repetitive assocation. • ObjectClass(mandatory): The Object Class containing the Association Business Information Entity. • PropertyTermQualifier (optional): A qualifier is a word or words which help define and differentiate the Association Business Information Entity. • PropertyTerm(mandatory): Property Term represents the Aggregate Business Information Entity contained by the Association Business Information Entity. • AssociatedObjectClassQualifier (optional): Associated Object Class Qualifiers describe the 'context' of the relationship with another ABIE. That is, it is the role the contained Aggregate Business Information Entity plays within its association with the containing Aggregate Business Information Entity. • AssociatedObjectClass (mandatory); Associated Object Class is the Object Class at the other end of this association. It represents the Aggregate Business Information Entity contained by the Association Business Information Entity. [DOC8] The xsd:documentation element for every Supplementary Component attribute declarationMUST contain a structured set of annotations in the following sequence and pattern: • Name (mandatory): Name in the Registry of a Supplementary Component of a Core Component Type. • Definition (mandatory): A clear, unambiguous and complete explanation of the meaning of a Supplementary Component and its relevance for the related Core Component Type. • Primitive type (mandatory): PrimitiveType to be used for the representation of the value of a Supplementary Component. • Possible Value(s) (optional): one possible value of a Supplementary Component. [DOC9] The xsd:documentation element for every Supplementary Component attribute declaration containing restrictions MUST include the following additional information appended to the information required by DOC8: • Restriction Value(s) (mandatory): The actual value(s) that is (are) valid for the Supplementary Component. Element Declaration rules [ELD2] All element declarations MUST be global [ELD3] For every class and property identified in the UBL model, a global element bound to the corresponding xsd:complexType MUST be declared. [ELD4] When a ccts:ASBIE is unqualified, it is bound via reference to the global ccts:ABIE element to which it is associated. [ELD6] The code list xsd:import element MUST contain the namespace and schema location attributes. [ELD7] Empty elements MUST not be declared, except in the case of extension, where the 'UBL Extensions' element is used. [ELD9] (See GXS14) [ELD10] The root element MUST be the only global element declared in document schemas. [ELD11] When a ccts:ASBIE is qualified, a new element MUST be declared and bound to the xsd:complexType of its associated ccts:ABIE. [ELD12] The 'UBL Extensions' element MUST be declared as the first child of the document element with xsd:minOccurs="0". [ELD13] The 'UBLProfileID' element MUST be declared immediately following the 'UBL Extensions' element with xsd:minOccurs="0". [ELD14] The 'UBLSubsetID' element MUST be declared immediately following the 'UBLProfileID' element with xsd:minOccurs="0". Element Naming rules [ELN1] A UBL global element name based on a ccts:ABIE MUST be the same as the name of the corresponding xsd:complexType to which it is bound, with the word “Type” removed. [ELN2] A UBL global element name based on a ccts:BBIEProperty MUST be the same as the name of the corresponding xsd:complexType to which it is bound, with the word “Type” removed. [ELN3] A UBL global element name based on a ccts:ASBIE MUST be the ccts:ASBIE dictionary entry name property term and its qualifiers; and the object class term and qualifiers of its associated ccts:ABIE. All ccts:DictionaryEntryName separators MUST be removed.. General Naming rules [GNR1] UBL XML element and type names MUST be in the English language, using the primary English spellings provided in the Oxford English Dictionary. [GNR2] UBL XML element and type names MUST be consistently derived from CCTS conformant dictionary entry names. [GNR3] UBL XML element and type names constructed from ccts:DictionaryEntryNames MUST NOT include periods, spaces, other separators, or characters not allowed by W3C XML 1.0 for XML names [GNR4] UBL XML element, and simple and complex type names MUST NOT use acronyms, abbreviations, or other word truncations, except those in the list of exceptions published in Appendix B. [GNR5] Acronyms and abbreviations MUST only be added to the UBL approved acronym and abbreviation list after careful consideration for maximum understanding and reuse. [GNR6] The acronyms and abbreviations listed in Appendix B MUST always be used in place of the word or phrase they represent. [GNR7] UBL XML element, and type names MUST be in singular form unless the concept itself is plural. [GNR8] The UpperCamelCase (UCC) convention MUST be used for naming elements and types. [GNR10] Acronyms and abbreviations at the beginning of an attribute name MUST appear in all lower case.  All other acronym and abbreviation usage in an attribute declaration MUST appear in upper case. [GNR11] Acronyms and abbreviations MUST appear in all upper case for all element declarations and type definitions. General Type Definition Rules [GTD1] All types MUST be named. [GTD2] The xsd:anyType MUST NOT be used. General XML Schema Rules [GXS1] UBL Schema MUST conform to the following physical layout as applicable: <!-- ======= XML Declaration======== --> <?xml version="1.0" encoding="UTF-8"?> <!-- ======= Schema Header ======= --> Document Name: < Document name as indicated in Section 3.6 > Generated On: < Date schema was generated > <!-- ===== Copyright Notice ===== --> “Copyright „ 2001-2004 The Organization for the Advancement of Structured Information Standards (OASIS). All rights reserved. <!-- ===== xsd:schema Element With Namespaces Declarations ===== --> xsd:schema element to include version attribute and namespace declarations in the following order: xmlns:xsd Target namespace Default namespace CommonAggregateComponents CommonBasicComponents CoreComponentTypes Unspecialized Unqualified Datatypes Specialized Qualified Datatypes Identifier Schemes Code Lists Attribute Declarations – elementFormDefault="”qualified"” attributeFormDefault="”unqualified"” Version Attribute <!-- ===== Imports ===== --> CommonAggregateComponents schema module CommonBasicComponents schema module Unspecialized Unqualified Types schema module Specialized Qualified Types schema module <!-- ===== Global Attributes ===== --> Global Attributes and Attribute Groups <!-- ===== Root Element ===== --> Root Element Declaration Root Element Type Definition <!-- ===== Element Declarations ===== --> alphabetized order <!-- ===== Type Definitions ===== --> All type definitions segregated by basic and aggregates as follows <!-- ===== Aggregate Business Information Entity Type Definitions ===== --> alphabetized order of ccts:AggregateBusinessInformationEntity xsd:TypeDefinitions <!-- =====Basic Business Information Entity Type Definitions ===== --> alphabetized order of ccts:BasicBusinessInformationEntities <!-- ===== Copyright Notice ===== --> Required OASIS full copyright notice. [GXS2] UBL MUST provide two normative schemas for each transaction. One schema shall be fully annotated. One schema shall be a run-time schema devoid of documentation. [GXS3] Built-in XSD Simple Types SHOULD be used wherever possible. [GXS4] All W3C XML Schema constructs in UBL Schema and schema modules MUST contain the following namespace declaration on the xsd schema element: xmlns:xsd="http://www.w3.org/2001/XMLSchema” [GXS5] The xsd:substitutionGroup feature MUST NOT be used. [GXS6] The xsd:final attribute MUST be used to control extensions where there is a desire to prohibit further extensions. [GXS7] xsd:notation MUST NOT be used. [GXS8] The xsd:all element MUST NOT be used. [GXS9] The xsd:choice element SHOULD NOT be used where customisation and extensibility are a concern. [GXS11] The xsd:union technique MUST NOT be used except for Code Lists. The xsd:union technique MAY be used for Code Lists. [GXS12] UBL designed schema SHOULD NOT use xsd:appinfo. If used, xsd:appinfo MUST only be used to convey non-normative information. [GXS13] Complex Type extension or restriction MAY be used where appropriate. [GXS14] The xsd:any element MUST NOT be used except within the 'ExtensionContentType' type definition, and with xsd:processContents= "skip" for non-UBL namespaces. [GXS15] Each xsd:schemaLocation attribute declaration MUST contain a system-resolvable URL, which at the time of release from OASIS shall be a relative URL referencing the location of the schema or schema module in the release package. [GXS16] The built in xsd:nillable attribute MUST NOT be used for any UBL declared element. [GXS17] The xsd:anyAttribute MUST NOT be used. Instance document rules [IND1] All UBL instance documents MUST validate to a corresponding schema. [IND2] All UBL instance documents MUST identify their character encoding within the XML declaration. [IND3] In conformance with ISO/IETF/ITU/UNCEFACT Memorandum of Understanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) as agreed to by OASIS, all UBL XML SHOULD be expressed using UTF-8. [IND4] All UBL instance documents MUST contain the following namespace declaration in the root element: xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” [IND5] UBL conformant instance documents MUST NOT contain an element devoid of content or null values, except in the case of extension, where the 'UBL Extensions' element is used. [IND6] The absence of a construct or data in a UBL instance document MUST NOT carry meaning except in the case of extension, where the 'UBL Extensions' element is used [IND7] All UBL instance documents MUST include an element named "UBLVersionID" as the first child of its root element, except in the case of extension, where the 'UBL Extensions' element is used. In the case of extension the 'UBLVersionID' element MUST be the second child of the document element. The value of this 'UBLVersionID' element MUST match the value of the xsd:version attribute of its controlling schema Modelling constraint rules [MDC1] UBL Libraries and Schemas MUST only use ebXML Core Component approved ccts:CoreComponentTypes, except in the case of extension, where the 'UBL Extensions' element is used [MDC2] Mixed content MUST NOT be used except where contained in an xsd:documentation element Naming constraint rules [NMC1] Each dictionary entry name MUST define one and only one fully qualified path (FQP) for an element or attribute. Namespace Rules [NMS1] Every UBL-defined –or -used schema module, except internal schema modules, MUST have a namespace declared using the xsd:targetNamespace attribute. [NMS2] Every UBL-defined-or -used major version schema set MUST have its own unique namespace. [NMS3] UBL namespaces MUST only contain UBL developed schema modules. [NMS4] The namespace names for UBL Schemas holding committee draft status MUST be of the form: urn:oasis:names:tc:ubl:schema:<subtype>:<document-id> [NMS5] The namespace names for UBL Schemas holding OASIS Standard status MUST be of the form: urn:oasis:names:specification:ubl:schema:<subtype>:<document-id> [NMS6] UBL published namespaces MUST never be changed. [NMS7] The ubl:CommonAggregateComponents schema module MUST reside in its own namespace. [NMS8] The ubl:CommonAggregateComponents schema module namespace MUST be represented by the namespace prefix “cac” when referenced in other schemas. [NMS9] The ubl:CommonBasicComponents schema module MUST reside in its own namespace. [NMS10] The UBL:CommonBasicComponents schema module namespace MUST be represented by the namespace prefix “cbc” when referenced in other schemas. [NMS15] The ubl:QualifiedDatatypes schema module MUST reside in its own namespace. [NMS16] The ubl:QualifiedDatatypes schema module namespace MUST be represented by the namespace prefix “qdt” when referenced in other schemas. [NMS17] The ccts:UnqualifiedDatatypes schema module namespace MUST be represented by the token “udt”when referenced in other schemas. [NMS18] The CommonExtensionComponent schema module namespace MUST be represented by the namespace prefix 'ext' when referenced in other schemas. Root element declaration rules [RED1] Every UBL instance document MUST validate to a UBL document schema. Schema structure modularity rules [SSM1] UBL Schema expressions MAY be split into multiple schema modules. [SSM2] A document schema in one UBL namespace that is dependent upon type definitions or element declarations defined in another namespace MUST only import the document schema from that namespace. [SSM3] A document schema in one UBL namespace that is dependant upon type definitions or element declarations defined in another namespace MUST NOT import internal schema modules from that namespace. [SSM4] Imported schema modules MUST be fully conformant with UBL naming and design rules. [SSM5] UBL schema modules MUST either be treated as external schema modules or as internal schema modules of the document schema. [SSM6] All UBL internal schema modules MUST be in the same namespace as their corresponding document schema. [SSM7] Each UBL internal schema module MUST be named {ParentSchemaModuleName}{InternalSchemaModuleFunction}{schema module} [SSM8] A UBL schema module MAY be created for reusable components. [SSM9] A schema module defining all UBL Common Aggregate Components MUST be created. [SSM10] The UBL Common Aggregate Components schema module MUST be identified as CommonAggregateComponents in the document name within the schema header. [SSM11] A schema module defining all UBLCommon Basic Components MUST be created. [SSM12] The UBL Common Basic Components schema module MUST be identified as CommonBasicComponents in the document name within the schema header. [SSM18] A schema module defining all UBL Qualified Datatypes MUST be created. [SSM19] The UBL Qualified Datatypes schema module MUST be identified as QualifiedDatatypes in the document name in the schema header. [SSM20] The UBL Qualified Datatypes schema module MUST import the ccts:UnQualifiedDatatypes schema module. SSM21 The UBL extensions schema module MUST be identified as CommonExtensionComponents in the document name within the schema header. Standards Adherence rules [STA1] All UBL schema design rules MUST be based on the W3C XML Schema Recommendations: XML Schema Part 1: Structures and XML Schema Part 2: Datatypes. [STA2] All UBL schema and messages MUST be based on the W3C suite of technical specifications holding recommendation status. Versioning rules [VER1] Every UBL Schema and schema module major version committee draft MUST have an RFC 3121 document-id of the form <name>-<major>[.<revision>] [VER2] Every UBL Schema and schema module major version OASIS Standard MUST have an RFC 3121 document-id of the form <name>-<major> [VER3] Every minor version release of a UBL schema or schema module draft MUST have an RFC 3121 document-id of the form <name>-<major>[.<revision>] [VER4] Every minor version release of a UBL schema or schema module OASIS Standard MUST have an RFC 3121 document-id of the form <name>-<major > [VER5] For UBL Minor version changes the namespace name MUST not change [VER6] Every UBL Schema and schema module major version number MUST be a sequentially assigned, incremental number greater than zero. [VER7] Every UBL Schema and schema module minor version number MUST be a sequentially assigned, incremental non-negative integer. [VER8] A UBL minor version document schema MUST import its immediately preceding version document schema. [VER9] UBL Schema and schema module minor version changes MUST be limited to the use of xsd:extension or xsd:restriction to alter existing types or add new constructs. [VER10] UBL Schema and schema module minor version changes MUST not break semantic compatibility with prior versions. [VER11] Every UBL Schema and schema module major version committee draft MUST capture its version number in the xsd:version attribute of the xsd:schema element in the form <major>.0[.<revision>] [VER12] Every UBL Schema and schema module major version OASIS Standard MUST capture its version number in the xsd:version attribute of the xsd:schema element in the form <major>.0 [VER13] Every minor version release of a UBL schema or schema module draft MUST capture its version information in the xsd:version attribute in the form <major>.<non-zero>[.<revision>] [VER14] Every minor version release of a UBL schema or schema module OASIS Standard MUST capture its version information in the xsd:version attribute in the form <major>.<non-zero> [VER15] Every UBL document schema MUST include a required element named "UBLVersionID" as the first child of its root element. This element MUST have a default value that matches the value of the xsd:version attribute of its containing schema. The following Acronyms and Abbreviations have been approved by the UBL NDR Subcommittee for UBL use: A Dun & Bradstreet Data Universal Numbering System (DUNS) number must appear as "DUNS". "Identifier" must appear as "ID". "Uniform Resource Identifier" must appear as "URI" [Example] the "Uniform Resource. Identifier" portion of the Binary Object. Uniform Resource. Identifier supplementary component becomes "URI" in the resulting XML name). The use of URI for Uniform Resource Identifier takes precedence over the use of "ID" for "Identifier". [CCTS]ISO 15000-5 ebXML Core Components Technical Specification [ISONaming] ISO/IEC 11179, Final committee draft, Parts 1-6. (RFC) 2119S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. [UBLChart] UBL TC Charter, http://oasis-open.org/committees/ubl/charter/ubl.htm [XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, October 6, 2000 (XSD) XML Schema, W3C Recommendations Parts 0, 1, and 2. 2 May 2001. (XHTML) XHTML™ Basic, W3C Recommendation 19 December 2000: http://www.w3.org/TR/2000/REC-xhtml-basic-20001219 [CCTS]ISO 15000-5 ebXML Core Components Technical Specification [ISONaming] ISO/IEC 11179, Final committee draft, Parts 1-6. (RFC) 2119S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. [UBLChart] UBL TC Charter, http://oasis-open.org/committees/ubl/charter/ubl.htm [XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, October 6, 2000 (XSD) XML Schema, W3C Recommendations Parts 0, 1, and 2. 2 May 2001. (XHTML) XHTML™ Basic, W3C Recommendation 19 December 2000: http://www.w3.org/TR/2000/REC-xhtml-basic-20001219