Appendix A - UBL XML Naming and Design Rules Checklist

Snapshot of NDR Rules as of September 179, 2003

This should table reflects the rules that were currentwritten and given to the LCSC as of September 179, 2003.

Key for Use:

· The original rule is first and not indented,

· The bulleted rule underneath is the changed version that will be reflected in the final release in January 2004.

· New rules that were not part of the September 17^th set of rules, but will be part of the final release are marked “NEW”.

Rule Number		Rule	Post Montreal Rule Number (This column will be deleted before publication)
Standards Adherence
[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. · 11/10/03, no changes.		[R1]
[STA2]	All UBL schema and messages MUST be based on the W3C suite of technical specifications holding recommendation status. · 11/10/03, no changes.		[2]
General XSD
[GXS1]		UBL MUST provide two normative schemas for each transaction. One schema shall be a run-time schema devoid of documentation. One schema shall be fully annotated. · 11/10/03, number changed to GXS2, no content change.	[R96] Mavis thinks this might not be the best thing to see first.
[GXS2]		Built-in Simple Types SHOULD be used wherever possible. · 11/10/03, number changed to GXS3, no content change.	[R 98]
[GXS3]		All W3C XML Schema constructs in UBL schema and Schema Modules MUST contain the following regular expression: xmlns:xsd="http://www.w3.org/2001/XMLSchema” · 11/10/03, no changes.	[R 107]
[GXS4]		The xsd:substitution groups feature MUST NOT be used. · 11/10/03, no changes.	[R 103] Stephen felt groups should be part.
[GXS5]		The xsd:final attribute MUST be used to control extensions. · 11/10/03, no changes.	[R 111]
[GXS6]		xsd:notations MUST NOT be used. · 11/10/03, no changes.	[R 114]
[GXS7]		The xsd:all element MUST NOT be used. · 11/10/03, no changes.	[R16b]
[GXS8]		The xsd:choice element MUST NOT be used. · 11/10/03, no changes.	[R16c]
[GXS9]		The xsd:include feature MUST only be used within a RootSchema. · 11/10/03 [GXS10] The xsd:include feature MUST only be used within a control schema.	[R45]
[GXS10]		The xsd:union technique MUST NOT be used except for Code Lists. The xsd:union technique MAY be used for Code Lists. · 11/10/03 [GXS11] The xsd:union technique MUST NOT be used except for Code Lists. The xsd:union technique MAY be used for Code Lists.	[R 100]
GXS12		UBL designed schema SHOULD NOT use xsd:appinfo. If used, xsd:appinfo MUST only be used to convey non-normative information. · 11/10/03, no changes.	[R 93]
NEW		[GXS13] Complex Type extension or restriction MAY be used where appropriate.
Namespace Mark, The Schema structure section should go before the Namespace section, may even need to go before the General XSD section for context.
[NMS1]		The CCTS:CCT Schema Module MUST reside in its own namespace. · 11/10/03 [NMS12] The ccts:CoreComponentType schema module MUST reside in its own namespace.	[R20c]
[NMS2]		The CCTS:CCT Schema Module namespace MUST be represented by the token “cct”. · 11/10/03 [NMS13] The ccts:CoreComponentType schema module namespace MUST be represented by the token “cct”.	[R20d]
[NMS3]		The CCTS:RepresentationTerm Schema Module MUST reside in its own namespace. · 11/10/03 [NMS14] The ccts:RepresentationTerm schema module MUST reside in its own namespace.	[R20i]
[NMS4]		The CCTS:RepresentationTerm Schema Module namespace MUST be represented by the token “rt”. · 11/10/03 [NMS15] The ccts:RepresentationTerm schema module namespace MUST be represented by the token “rt”.	[R20j]
[NMS5]		The UBL:Datatypes Schema Module MUST reside in its own namespace. · 11/10/03 [NMS16] The ubl:Datatypes schema module MUST reside in its own namespace.	[R20m]
[NMS6]		The UBL:Datatypes Schema Module namespace MUST be represented by the token “dt”. · 11/10/03 [NMS17] The ubl:Datatypes schema module namespace MUST be represented by the token “dt”.	[R20n]
[NMS7]		Each UBL:CodeList Schema Module MUST be maintained in a separate namespace. · 11/10/03 number changed to NMS19, no content changes.	[R29d]
[NMS8]		Every UBL defined or used Schema Module MUST have a namespace declared. · 11/10/03, [NMS2] Every UBL defined or used schema set version MUST have its own unique namespace.	[R34a]
[NMS9]		Every UBL defined or used Schema Module version MUST have its own unique namespace. · 11/10/03 Number change, changed to NMS2, no content change.	[R 46]
[NMS10]		UBL namespaces MUST only contain UBL developed Schema Modules. · 11/10/03 Number change, changed to NMS3, no content change.	[R34b]
[NMS11]		The namespace names for UBL Schemas holding draft status MUST be of the form: urn:oasis:names:tc:ubl:schema:name:major:minor · 11/10/03 (NMS4) The namespace names for UBL Schemas holding committee draft status MUST be of the form: urn:oasis:names:tc:ubl:schema:<name>:<major>:<minor>[<revision>]	[R36]
[NMS11]		The namespace names for UBL Schemas holding specification status MUST be of the form: urn:oasis:names:specification:ubl:schema:name:major:minor · 11/10/03 (NMS5) The namespace names for UBL Schemas holding OASIS Standard status MUST be of the form: urn:oasis:names:specification:ubl:schema:<name>:<major>:<minor>	[R 37]
[NMS12]		UBL Schema modules MUST be hosted under the UBL committee directory: http://www.oasis-open.org/committees/ubl/schema/<schema-mod-name>.xsd · 11/10/03 Number changed to NMS6, no content change.	[R 39]
[NMS13]		UBL published namespaces MUST never be changed. · 11/10/03, number changed to NMS7, no content change.	[R 48]
NEW		· 11/10/03 [NMS8] The ubl:CommonAggregateComponents schema module MUST reside in its own namespace. · 11/10/03 [NMS9] The ubl:CommonAggregateComponents schema module MUST be represented by the token “cac”.
NEW		· 11/10/03 [SSM11] A schema module defining all ubl:CommonBasicComponents MUST be created. · 11/10/03 [SSM12] The ubl:CommonBasicComponents schema module MUST be named “ubl:CommonBasicComponents Schema Module” · 11/10/03 [NMS10] The ubl:CommonBasicComponents schema module MUST reside in its own namespace. · 11/10/03 [NMS11] The UBL:CommonBasicComponents schema module MUST be represented by the token “cbc”.
Versioning
[VER1]		Every UBL Schema and Schema Module Major version MUST have the URI of: urn:oasis:names:tc:ubl:name:major-number:0 · 11/10/03 Every UBL Schema and schema module major version committee draft MUST have the URI of: urn:oasis:names:tc:ubl:schema:<name>:<major>:0:[<revision>] · 11/10/03 Every UBL Schema and schema module major version OASIS Standard MUST have the URI of: urn:oasis:names:specification:ubl:schema:<name>:<major>:0	[R40]
[VER2]		The first minor version release of a UBL Schema or Schema Module MUST have the URI of: urn:oasis:names:tc:ubl:name:major-number:non-zero · 11/10/03 The first minor version release of a UBL Schema or schema module committee draft MUST have the URI of: urn:oasis:names:tc:ubl:schema:<name>:<major-number>:<non-zero>:[<revision>] · 11/10/03 The first minor version release of a UBL schema or schema module OASIS Standard MUST have the URI of: urn:oasis:names:specification:ubl:schema:name:major-number:non-zero	[R41a] Should this be a colon?
[VER3]		For UBL Minor version changes, the name of the version construct MUST NOT change (short name not qualified name), unless the intent of the change is to rename the construct. · 11/10/03 number changed to VER5, no content changed.	[41b]
[VER4]		Every UBL Schema and Schema Module major version number MUST be a non-negative integer. · 11/10/03 Every UBL Schema and schema module major version number MUST be sequentially assigned, incremental number greater than zero.	[R43a]
[VER5]		Every UBL Schema and Schema Module minor version number MUST be a non-negative integer. · 11/10/03 Every UBL Schema and schema module minor version number MUST be a sequentially assigned, incremental non-negative integer.	[R43b]
[VER6]		Each UBL minor version MUST be given a separate namespace. · 11/20/03 no change.	[R47]
[VER7]		When a UBL URN changes to reflect a change in the namespace, this change MUST be reflected in the version number, either major or minor. · 11/10/03, not in newer version, rewritten to reflect in other rules.	[R49]
[VER8]		UBL Schema and Schema Module minor versioning MUST be limited to declaring new optional constructs, extending existing constructs, and refinements of an optional nature. · 11/10/03 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.	[R50]
[VER9]		UBL Schema and Schema Module minor version changes MUST not break semantic compatibility with prior versions. · 11/10/03 no changes.	[R51]
[VER10]		UBL minor version namespaces MUST reference immediately preceding minor version root Schemas. · 11/10/03 A UBL minor version control schema MUST import its immediately preceding minor version control schema.	[R52]
Constraints
Naming Constraints
[NMC1]		Each dictionary entry name MUST define one and only one fully qualified path (FQP) for an element or attribute. · 11/10/03, no changes.	[R3]
Modeling Constraints
[MDC1]		UBL Models MUST define classes based on ebXML Core Component Basic Business Information Entities and Aggregate Business Information Entities. · 11/10/03, UBL Models MUST define classes based on ebXML ccts:BasicBusinessInformationEntities and ccts:AggregateBusinessInformationEntities.	[R13a]
[MDC2]		UBL Libraries and Schemas MUST only use ebXML Core Component approved Core Component Types. · 11/10/03, UBL Libraries and Schemas MUST only use ebXML Core Component approved ccts:CoreComponentTypes.	[R61]
[MDC3]		If a UBL message set is extended it MUST retain the business function of the original UBL message set. · 11/10/03, If a UBL document is customized it MUST retain the business function of the original UBL document.	[R81]
[MDC4]		Mixed content MUST NOT be used except where contained in an xsd:documentation element. · 11/10/03, No change.	[R 97]
Naming Rules
General Naming rules
[GNR1]		UBL XML element, attribute and type names MUST be in the English language, using the primary English spellings provided in the Oxford English Dictionary. · 11/10/03, no changes.	[R4]
[GNR2]		UBL XML element, attribute and type names MUST be taken from CCTS conformant dictionary entry names. · 11/10/03, no changes.	[R5a] Rule 5 had been deleted in the last version of the checklist.
[GNR3]		UBL XML element, attribute 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. · 11/10/03, no changes.	[R5b] Rule 5 had been deleted in the last version of the checklist.
[GNR4]		UBL XML Element, attribute, and Simple and complex type names MUST NOTuse acronyms, abbreviations, or other word truncations, except those in the list of exceptions published in Appendix B. · 11/10/03, no changes.	[R5/87]
[GNR5]		Acronyms and abbreviations MUST only be added to the UBL approved acronym and abbreviation list after careful consideration for maximum understanding and reuse. · 11/10/03, no changes.	[R88]
[GNR6]		Acronyms and abbreviations added to the UBL approved list MUST only be taken from the latest version of the Pocket Oxford English Dictionary. The first occurrence listed for a word MUST be used. · 11/10/03, no changes.	[R89]
[GNR7]		The acronyms and abbreviations listed in Appendix B MUST always be used. · 11/10/03, no changes.	[R90]
[GNR8]		UBL XML element, attribute and type names MUST be in singular form unless the concept itself is plural (example: Goods). · 11/10/03, no changes.	[R8]
[GNR9]		The UpperCamelCase (UCC) convention MUST be used for naming elements and types. · 11/10/03, no changes.	[R9]
[GNR10]		The lowerCamelCase (LCC) convention MUST be used for naming attributes. · 11/10/03, no changes.	[R10]
Specific Naming Rules
Elements
[ELN1]		A UBL global element name based on an CCTS:ABIE MUST be the same as the name of the corresponding xsd:complexType to which it is bound, with the word “Type” removed. · 11/10/03, no changes.	[R15a]
[ELN2]		A UBL global element name based on a CCTS:BBIE MUST be the same as the name of the corresponding xsd:complexType to which it is bound, with the word “Type” removed. · 11/10/03, no changes.	[R15b]
[ELN3]		A UBL global element name based on an CCTS:ASBIE MUST be declared and bound to the xsd:complexType of its associated CCTS:ABIE. · 11/10/03, no changes.	[R15c]
[ELN4]		A UBL global element name based on an CCTS:ASBIE MUST be the CCTS:ASBIE dictionary entry name property term and qualifiers; and the object class term and qualifiers of its associated CCTS:ABIE. All CCTS:DictionaryEntryName separators MUST be removed. Redundant words in the CCTS:ASBIE property term or qualifiers and the associated CCTS:ABIE object class term or qualifiers MUST be dropped. · 11/10/03, no changes.	[R15d]
Attributes
[ATN1]		Each CCT:SupplementaryComponent xsd:attribute “name” MUST be the CCTS:SupplementaryComponent dictionary entry name property term and representation term, with the separators removed. · 11/10/03, no changes.	[21h]
Types
[CTN1]		A UBL xsd:complexType name based on an CCTS:ABIE MUST be the CCTS:DictionaryEntryName with the separators removed and with the “Details” suffix replaced with “Type”. · 11/10/03, no changes.	[R14a], [R14b]
[CTN2]		A UBL xsd:complexType name based on a CCTS:BBIE MUST be the CCTS:DictionaryEntryName property term and qualifiers and representation term, with the separators removed and with the “Type” suffix appended after the representation term. · 11/10/03, no changes.	[R14c]
[CTN3]		A UBL xsd:complexType name based on a primary representation term used in the UBL model MUST be the name of the corresponding CCTS:CCT, with the separators removed and with the “Type” suffix appended after the primary representation term name. · 11/10/03, no changes.	[R14d]
[CTN4]		A UBL xsd:complexType name based on a secondary representation term used in UBL model MUST be the name of the secondary representation term, with the separators removed and with the “Type” suffix appended after the secondary representation term name. · 11/10/03, no changes.	[R14e]
[CTN5]		A UBL xsd:complexType name based on a CCTS:CCT MUST be the Dictionary entry name of the CCTS:CCT, with the separators removed. · 11/10/03, no changes.	[R14f]
Schema Structure
Modularity
[SSM1]		UBL Schema expressions MAY be split into multiple Schema Modules. · 11/10/03 no changes.	[R35a]
[SSM2]		UBL Schema Modules MUST either be treated as external Schema Modules or as internal Schema Modules of the root Schema. · 11/10/03 (SSM5) UBL schema modules MUST either be treated as external schema modules or as internal schema modules of the control schema.	[R35b]
[SSM3]		All UBL internal Schema Modules MUST be in the same namespace as their corresponding root Schema. · 11/10/03 (SSM6) All UBL internal schema modules MUST be in the same namespace as their corresponding control schema.	[R35c]
[SSM4]		Each UBL internal Schema Module MUST be named {ParentSchemaModuleName}{InternalSchemaModuleFunction}{Schema Module} · 11/10/03 number changed to SSM7, no content change.	[R35d]
[SSM5]		A UBL Schema Module MAY be created for Reusable types. · 11/10/03 (SSM8) A UBL schema module MAY be created for reusable components.	[R44a]
[SSM6]		A root schema in one UBL namespace that is dependent upon type definitions or element declaration defined in another namespace MUST only import the RootSchema from that namespace. · 11/10/03 (SSM2) A control schema in one UBL namespace that is dependent upon type definitions or element declaration defined in another namespace MUST only import the control schema from that namespace.	[R44b]
[SSM7]		A UBL root schema in one UBL namespace that is dependant upon type definitions or element declarations defined in another namespace MUST NOT import Schema Modules from that namespace. · 11/10/03 (SSM3) A UBL control 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.	[R44c]
[SSM8]		Imported Schema Modules MUST be fully conformant with UBL naming and design rules. · 11/10/03 number changed to SSM4, no content change.	[R44d]
[SSM9]		A Schema Module defining all CCTS:CCTs MUST be created. · 11/10/03 [SSM13] A schema module defining all ccts:CoreComponentTypes MUST be created.	[R20a]
[SSM10]		The CCTS:CCT Schema Module MUST be named “CCTS:CCT Schema Module” · 11/10/03 [SSM14] The ccts:CoreComponentType schema module MUST be named “ccts:CoreComponentType Schema Module”	[R20b]
[SSM11]		The xsd:facet feature MUST not be used in the CCTS:CCT Schema Module. · 11/10/03 [SSM15] The xsd:facet feature MUST not be used in the ccts:CoreComponentType schema module.	[R20e]
[SSM12]		A Schema Module defining all CCTS:PrimaryRepresentationTerms and CCTS:SecondaryRepresentationTerms MUST be created. · 11/10/03 [SSM16] A schema module defining all ccts:PrimaryRepresentationTerms and ccts:SecondaryRepresentationTerms with the exception of ccts:CodeType MUST be created	[R20g]
[SSM13]		The CCTS:RepresentationTerm Schema Module MUST be named “CCTS Representation Term Schema Module” · 11/10/03 [SSM17] The ccts:RepresentationTerm schema module MUST be named “ccts:RepresentationTerm Schema Module”	[R20h]
[SSM14]		A Schema Module defining all UBL Datatypes MUST be created. · 11/10/03 [SSM18] A schema module defining all ubl:Datatypes MUST be created.	[R20k] SG: I didn’t think we kept this rule? Please query.
[SSM15]		The UBL:Datatypes Schema Module MUST be named “UBL Datatypes Schema Module” · 11/10/03 [SSM19] The UBL:Datatypes schema module MUST be named “ubl:Datatypes schema module”	[R20l] to match SSM13.
NEW		11/10/03 [SSM9] A schema module defining all ubl:CommonAggregateComponents MUST be created. 11/10/03 [NMS8] The ubl:CommonAggregateComponents schema module MUST reside in its own namespace.
Root Element Declaration
[RED1]		Every UBL business document MUST have a single root element. · 11/10/03, no changes.	[R11]
[RED2]		Every root element in a UBL document MUST be named according to the portion of the business process that it initiates. · 11/10/03, no changes.	[R12]
Documentation
[DOC1]		Every type definition and element declaration MUST contain a structured set of annotations in the following pattern: a) UBL UID: The unique identifier assigned to the type in the UBL library. b) UBL Name: The complete name (not the tag name) of the type per the UBL library. c) Object Class: The Object Class represented by the type. d) Dictionary Entry Name: The complete name (not the tag name), which is the unique official name of the BIE or the property in the UBL library. e) UBL Definition: Documentation of how the type is to be used, written such that it addresses the type's function as a reusable component. f) Code Lists/Standards: A list of potential standard code lists or other relevant standards that could provide definition of possible values not formally expressed in the UBL structural definitions. g) Core Component UID: The UID of the Core Component on which the Type is based h) Business Process Context: A valid value describing the Business Process contexts for which this construct has been designed. Default is "In All Contexts". i) Geopolitical/Region Context: A valid value describing the Geopolitical/Region contexts for which this construct has been designed. Default is "In All Contexts". j) Official Constraints Context: A valid value describing the Official Constraints contexts for which this construct has been designed. Default is "None". k) Product Context: A valid value describing the Product contexts for which this construct has been designed. Default is "In All Contexts" l) Industry Context: A valid value describing the Industry contexts for which this construct has been designed. Default is "In All Contexts". m) Role Context: A valid value describing the Role contexts for which this construct has been designed. Default is "In All Contexts". n) Supporting Role Context: A valid value describing the Supporting Role contexts for which this construct has been designed. Default is "In All Contexts". o) System Capabilities Context: A valid value describing the Systems Capabilities contexts for which this construct has been designed. Default is "In All Contexts". p) All relevant metadata as specified in CCTS Section 7 for the concept (CCTS:BBIE, CCTS:ABIE, CCTS:ASBIE, CCTS:CCT, CCTS:RepresentationTerm, CCTS:Datatype) being conveyed. 11/10/03, This list has changed, but rule remains the same: · UniqueIdentifier (mandatory): The identifier that references a Data Type instance in a unique and unambiguous way. · CategoryCode (mandatory): The category to which the object belongs. For example, BBIE, ABIE, ASBIE, RT (Representation Term). · DictionaryEntryName (mandatory): The official name of a Data Type. · Definition (mandatory): The semantic meaning of a Data Type. · Version (mandatory): An indication of the evolution over time of a Data Type instance. · QualifierObjectClass (optional): The qualifier for the object class. · ObjectClass: The Object Class represented by the Data Type. · Qualifier Term (mandatory): A semantically meaningful name that differentiates the Data Type from its underlying Core Component Type. · Usage Rule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Data Type.	[R31]
[DOC2]		For each UBL construct containing a code, the UBL documentation MUST identify the zero or more code lists that MUST be minimally supported when the construct is used. · [DOC9] For each UBL construct containing a code, the UBL documentation MUST identify the zero or more code lists that MUST be minimally supported when the construct is used. § Prefix (mandatory): The code prefix, for example "cnt" for Country Code List. § CodeListQualifier (mandatory): The qualifier for the codelist, for example "ISO 3166-1". § CodeListAgency: The maintainer of the codelist, for example "6". § CodeListVersion: The version of the codelist, for example "0.3".	[R65]
NEW		· [DOC2] A Data Type definition MAY contain one or more Content Component Restrictions to provide additional information on the relationship between the Data Type 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.
NEW		[DOC3] A Data Type definition MAY contain one or more Supplementary Component Restrictions to provide additional information on the relationship between the Data Type 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 Component.
NEW		[DOC4] Every Basic Business Information Entity definition MUST contain a structured set of annotations in the following patterns: · Unique Identifier (mandatory): The identifier that references a Basic Business Information Entity instance in a unique and unambiguous way. · CategoryCode (mandatory): The category to which the object belongs. In this case the value will always be BBIE. · Dictionary Entry Name (mandatory): The official name of a Basic Business Information Entity. · Version (mandatory): An indication of the evolution over time of a Basic Business Information Entity instance. · Definition (mandatory): The semantic meaning of a Basic Business Information Entity. · Cardinality (mandatory): Indication whether the Basic Business Information Entity Property represents a not-applicable, optional, mandatory and/or repetitive characteristic of the Aggregate Business Information Entity. · QualifierTerm (optional): Qualifies the Property Term of the associated Core Component Property in the associated Aggregate Core Component. · UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Basic Business Information Entity. · ConstraintLanguage (optional, repetitive): A formal description of a way the Basic Business Information Entity is derived from the corresponding stored Core Component and stored Business Context. · BusinessTerm (optional, repetitive): A synonym term under which the Basic Business Information Entity is commonly known and used in the business. · Example (optional, repetitive): Example of a possible value of a Basic Business Information Entity.
NEW		[DOC5] Every Aggregate Business Information Entity definition MUST contain a structured set of annotations in the following patterns: · UniqueIdentifier (mandatory): The identifier that references an Aggregate Business Information Entity instance in a unique and unambiguous way. · CategoryCode (mandatory): The category to which the object belongs. In this case the value will always be ABIE. · Version (mandatory): An indication of the evolution over time of an Aggregate Business Information Entity instance. · DictionaryEntryName (mandatory): The official name of an Aggregate Business Information Entity. · Definition (mandatory): The semantic meaning of an Aggregate Business Information Entity. · QualifierTerm (mandatory): Qualifies the Object Class Term of the associated Aggregate Core Component. · UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Aggregate Business Information Entity. · ConstraintLanguage (optional, repetitive): A formal description of a way the Aggregate Business Information Entity is derived from the corresponding stored Core Component and stored Business Context. · BusinessTerm (optional, repetitive): A synonym term under which the Aggregate Business Information Entity is commonly known and used in the business. · Example (optional, repetitive): Example of a possible value of an Aggregate Business Information Entity.
NEW		[DOC6] Every Association Business Information Entity definition MUST contain a structured set of annotations in the following patterns: · UniqueIdentifier (mandatory): The identifier that references an Association Business Information Entity instance in a unique and unambiguous way. · CategoryCode (mandatory): The category to which the object belongs. In this case the value will always be ASBIE. · DictionaryEntryName (mandatory): The official name of an Association Business Information Entity. · Definition (mandatory): The semantic meaning of an Association Business Information Entity. · Version (mandatory): An indication of the evolution over time of an Association Business Information Entity instance. · Cardinality (mandatory): Indication whether the Association Business Information Entity Property represents a not-applicable, optional, mandatory and/or repetitive characteristic of the Aggregate Business Information Entity. · QualifierTerm (optional): Qualifies the Property Term of the associated Core Component Property in the associated Aggregate Core Component. · UsageRule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Association Business Information Entity. · ConstraintLanguage (optional, repetitive): A formal description of a way the Association Business Information Entity is derived from the corresponding stored Core Component and stored Business Context. · BusinessTerm (optional, repetitive): A synonym term under which the Association Business Information Entity is commonly known and used in the business. · Example (optional, repetitive): Example of a possible value of an Association Business Information Entity.
NEW		[DOC7] Every Core Component definition MUST contain a structured set of annotations in the following patterns: · UniqueIdentifier (mandatory): The identifier that references a Core Component instance in a unique and unambiguous way. · CategoryCode (mandatory): The category to which the object belongs. In this case the value will always be CCT. · DictionaryEntryName (mandatory): The official name of a Core Component. · Definition (mandatory): The semantic meaning of a Core Component. · ObjectClass: The Object Class represented by the type. · PropertyTerm: The Property Term represented by the type. · Version (mandatory): An indication of the evolution over time of a Core Component instance. · Usage Rule (optional, repetitive): A constraint that describes specific conditions that are applicable to the Basic Business Information Entity. · Business Term (optional, repetitive): A synonym term under which the Basic Business Information Entity is commonly known and used in the business.
Code Lists
[CDL1]		All UBL Codes MUST be part of a UBL or External maintained Code List. · 11/20/03 All UBL Codes MUST be part of a UBL or externally maintained Code List.	[R29a]
[CDL2]		The UBL Library SHOULD identify and use external standardized code lists rather than develop its own UBL-native code lists. · 11/10/03 no changes.	[R62]
[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. · 11/10/03 no changes.	[R63]
[CDL4]		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). · 11/10/03 no changes.	[R64]
[CDL5]		All UBL maintained or used Code Lists MUST be enumerated using the UBL Code List Schema Module. · 11/10/03 no changes.	[R29c]
[CDL6]		The name of each UBL Code List Schema Module MUST be of the form: {Owning Organization}[Code List Name}{Code List Schema Module} · 11/10/03 no changes.	[R29b]
[CDL7]		An xsd:Import element MUST be declared for every code list required in a UBL schema. · 11/10/03 no changes.	[R29e]
[CDL8]		Users of the UBL Library may identify any subset they wish from an identified code list for their own trading community conformance requirements. · 11/10/03 no changes.	[R66]
NEW		[CDLX] The namespace name of each UBL Code List Schema Module MUST conform to the following pattern: urn:oasis:ubl:codeList:<Code List.Identification.Identifier>:<Code List.Name.Text>:<Code List.Version.Identifier>:<Code List.Agency.Identifier>:<Code List. AgencyName.Text>
NEW		[CDLXX] The tokens comprising the URN MUST adhere to the following guidelines Whitespace MUST NOT be used within the URN. · Special characters MUST NOT be used within the URN. Special characters are those characters outside of the range 0-9 or a-z or A-Z. · Ed.Note what is the rule on using lowercase letters · If the code list version identifies a minor version then the major and minor version of the code list MUST be separated by a period (.).
NEW		[CDLXXX] The xsd:schemaLocation MUST include the complete URI used to identify the relevant code list schema.
Declarations
Element Declarations
[ELD1]		All element declarations MUST be global with the exception of ID and Code which MUST be local. · 11/10/03, Number change only, this was ELD2, now ELD1.	[R 92]
[ELD2]		Each UBL Schema MUST declare one global element that defines the overall business process being conveyed in the Schema expression. That global element declaration MUST include an xsd:annotation child element which MUST further contain an xsd:documentation child element that declares “This element MUST be conveyed as the root element in any instance document based on this Schema expression.” · 11/10/03, Each UBL:ControlSchema MUST identify one global element declaration that defines the overall business process being conveyed in the Schema expression. That global element MUST include an xsd:annotation child element which MUST further contain an xsd:documentation child element that declares “This element MUST be conveyed as the root element in any instance document based on this Schema expression.”	[R33] This was still in the “Hold For Review”, when did it move up?
[ELD3]		For every class identified in the UBL model, a global element bound to the corresponding xsd:complexType MUST be declared. · 11/10/03, no changes.	[R13c]
[ELD4]		CCTS:CCT simple and xsd:complexTypes MUST only be bound to elements that represent a BCC or a BBIE. · 11/10/03, no changes.	[R21d]
[ELD5]		For each CCTS:CCT simpleType, a xsd:restriction element MUST be declared. · 11/10/03, no changes.	[R23b] In codelist we may have used Extension instead of Restriction.
[ELD6]		The code list xsd:import element MUST contain the namespace and schema location attributes. · 11/10/03, no changes.	[R29f]
[ELD7]		Empty elements MUST not be declared. · 11/10/03, no changes.	[R94a]
[ELD6]		The xsd:any element MUST NOT be used. · 11/10/03, number changed to ELD8, no content change.	[R95a]
Attribute Declarations
[ATD1]		User defined attributes SHOULD NOT be used. When used, user defined attributes MUST only convey CCT:SupplementaryComponent information. · 11/10/03, no changes.	[R21a]
[ATD2]		If a CCTS:SupplementaryComponent xsd:attribute is common to all UBL elements, it MUST be declared as part of a global attribute group in the CCTS:CCT Schema Module. · 11/10/03, no changes.	[R26a]
[ATD3]		Within the CCTS:CCT xsd:extension element an xsd:attribute MUST be declared for each CCTS:SupplementaryComponent pertaining to that CCTS:CCT. · 11/10/03, no changes.	[R21g] Gunther had said this is not necessarily the case, we should check.
[ATD4]		For each CCTS:CCT simpleType xsd:Restriction element, an xsd:base attribute MUST be declared. · 11/10/03, no changes.	[R23c]
[ATD5]		Each CCTS:CCT simpleType xsd:Restriction element xsd:base attribute value MUST be set to the appropriate xsd:datatype. · 11/10/03, no changes.	[R23d]
[ATD6]		If a UBL xsd:SchemaExpression contains one or more common attributes that apply to all UBL elements contained or included or imported therein, the common attributes MUST be declared as part of a global attribute group. · 11/10/03, no changes.	[R26b]
[ATD7]		Each xsd:schemaLocation attribute declaration MUST contain a persistant and resolvable URL. · 11/10/03, no changes.	[R38a]
[ATD8]		Each xsd:schemaLocation attribute declaration URL MUST contain an absolute path. · 11/20/03, added to the end of text: To identify schema modules relative paths are not allowed. Although this may cause a problem with mirror sites, this is outside the scope of UBL.	[R38b] In packaging we have used relative paths for the release, how does this rule affect that?
[ATD9]		The xsd built in nillable attribute MUST NOT be used for any UBL declared element. · 11/10/03, no changes.	[R94b]
[ATD10]		The xsd:any attribute MUST NOT be used. · 11/10/03, no changes.	[R95b]
Type Definitions
General Type Definitions
[GTD1]		All types MUST be named. · 11/10/03, no changes.	[R91]
[GTD2]		The xsd:any Type MUST NOT be used. · 11/10/03, no changes.	[R95c]
Simple Type Definitions
[STD1]		For every CCTS:CCT whose supplementary components are equivalent to the properties of a built-in xsd:datatype, the CCT:SupplementaryComponents MUST NOT be expressed as attributes, and the CCTS:CCT MUST be defined as a named simpleType in the CCTS:CCT Schema Module. · 11/10/03, no changes.	[R21b]
[STD2]		xsd:simpleType restriction MUST NOT be used for CCTS:CCTs. · 11/10/03, number changed to STD3, no content change.	[R 99]
New		[STD2] Each ccts:CCT simpleType definition name MUST be the ccts:CCT dictionary entry name with the separators removed.
Complex Type Definitions
[CTD1]		For every class identified in the UBL model, a named xsd:complexType MUST be defined. · 11/10/03, no changes.	[R13b]
[CTD2]		For every primary representation term used in the UBL model, a named xsd:complexType MUST be defined. · 11/10/03, no changes.	[R13d]
[CTD3]		For every secondary representation term used in the UBL model, a named xsd:complexType MUST be defined. · 11/10/03, no changes.	[R13e]
[CTD4]		Every CCTS:ABIE xsd:complexType definition content model MUST use the xsd:sequence element with appropriate global element references, or local element declarations in the case of ID and Code, to reflect each property of its class as defined in the corresponding UBL model. · 11/10/03, no changes.	[R16a]
[CTD5]		Every CCTS:BBIE xsd:complexType definition content model MUST use the xsd:simpleContent element. · 11/10/03, no changes.	[R16d]
[CTD6]		Every CCTS:BBIE ComplexType content model xsd:simpleContent element MUST consist of an xsd:extension element. · 11/10/03, no changes.	[R16e]
[CTD7]		Every CCTS:BBIE xsd:complexType content model xsd:extension element MUST use the xsd:base attribute to define the basis of each primary or secondary representation term. · 11/10/03, no changes.	[R16f]
[CTD8]		Every CCTS:BBIE xsd:complexType content model xsd:base attribute value MUST be the CCTS:CCT of the primary representation term or the datatype of the secondary representation term as appropriate. · 11/10/03, no changes.	[R16g]
[CTD9]		For every CCTS:CCT whose supplementary components are not equivalent to the properties of a built-in xsd:datatype, the CCTS:CCT MUST be defined as a named xsd:complexType in the CCTS:CCT Schema Module. · 11/10/03, no changes.	[R21c] ELD4 and ELD5 seem to contradict (or one of the rules becomes illegal by another rule). And why are they in separate sections? STD2 is another rule that contradicts ELD5.
[CTD10]		Each CCTS:CCT xsd:complexType definition MUST contain one xsd:simpleContent element. · 11/10/03, no changes.	[R21e]
[CTD11]		The CCTS:CCT xsd:complexType definition xsd:simpleContent element MUST contain one xsd:extension element. This xsd:extension element MUST include an xsd:base attribute that defines the specific xsd:built-inDatatype required for the CCTS:ContentComponent of the CCTS:CCT. · 11/10/03, no changes.	[R21f] This seems to contradict ELD4 and ELD5, and why are they in separate sections.
[CTD12]		Each CCT:SupplementaryComponent xsd:attribute “type” MUST define the specific xsd:built-inDatatype or the user defined xsd:simpleType for the CCTS:SupplementaryComponent of the CCTS:CCT. · 11/10/03, no changes.	[R21i] CCT does not allow simpleType according to rule CTD9 – we are confused.
[CTD13]		Each CCTS:SupplementaryComponent xsd:attribute user-defined xsd:simpleType MUST only be used when the CCTS:SupplementaryComponent is based on a standardized code list for which a UBL conformant code list Schema Module has been created. · 11/10/03, no changes.	[R21j]
[CTD14]		Each CCTS:SupplementaryComponent xsd:attribute user defined xsd:simpleType MUST be the same xsd:simpleType from the appropriate UBL conformant code list Schema Module for that type. · 11/10/03, no changes.	[R21k]
[CTD15]		Each CCTS:Supplementary Component xsd:attribute “use” MUST define the occurence of that CCTS:SupplementaryComponent as either “required”, or “optional.” · 11/10/03, no changes.	[R21l]
[CTD16]		Each CCTS:CCT simpleType definition name MUST be the CCTS:CCT dictionary entry name with the separators removed. · 11/10/03, no changes.	[R23a]
Instance Documents
[IND1]		All UBL instance documents MUST validate to a corresponding schema. · 11/10/03, no changes.	[R84]
[IND2]		All UBL instance documents MUST always identify their character encoding with the XML declaration. · 11/10/03, no changes.	[R83]
??[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. · 11/10/03, no changes.	[R5c] Rule number 5 had been deleted in previous version.
[IND43]		All UBL instance documents MUST contain the following regular expression: xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”. · 11/10/03, no changes.	[R 108]
[IND54]		UBL conformant instance documents MUST NOTcontain an element devoid of content. · 11/10/03, no changes.	[R94c]
[IND65]		The absence of a construct or data in a UBL instance document MUST NOT carry meaning. · 11/10/03, no changes.	[R 102]
Not Yet Approved
[R 105]		ID/IDREF MUST NOT be used. [Ed Note - on hold]
[R 106]		Key/KeyRef MAY be used. [Ed Note - on hold]
[R 109]		Abstract xsd:complexTypes MAY be used (for UBL ur-schema). [Ed Note - On hold pending CM input]
[R 110]		Complex Type extension SHOULD be used where appropriate. [Ed Note - on hold pending CM input]
[R 112]		The block attribute MUST be used to control extensions. [Ed Note - On Hold pending CM input]
[R 113]		Complex type restriction SHOULD be used. [Ed Note - on hold pending CM input]
Rescinded.		All non-repeatable BIEs that are direct children of the document-levelBIE in the model will be child elements of a generated "Top" element in the schema. The generated "Top" element will be named "[doctype]Top", and itscontent model will be a sequence. It will reference a generated type named"[doctype]TopType". Both the generated "Top" element and its type will bedeclared in the same namespace as the document-level element. (Note: Thisrule implies that all documents will have generated "Top" elements, withoutexception, regardless of their other 'body' contents, to cover cases wherethe document will be extended with the Context mechanism, and for generalconsistency.)	[R115a
		[R 115b] All repeatable BIEs in the model will have generated containers. The containers will be named "[name_of_repeatable_element]List". These containers will be required if the cardinality of their contained immediate children requires at least one; if their contained children are optional; the container itself will be optional. At least one of the repeatable children of the List will always be required, but there may be more than one required child if that agrees with the cardinality found in the business model. All "_____List" elements will reference a "_______ListType", which will be declared in the same namespace as the element that represents the repeatable BIE in the business model. The content model of this type will have a single child element, which will have a maximum occurrence that reflects the maximum occurrence in the business model, and a minimum occurrence as described in this rule, above. (NOTE: This rule applies equally to 'list' containers at the document level, and also at lower levels within the document.) [R 115c] The document element in the schema will have a content model that is a sequence of elements, the first of which will be the "Top" element, and the others will be the generated "List" elements, in the order in which their contained, repeatable children appeared in the model. [R 115d] All elements in the generated schema that are direct children of the generated "top" elements in all documents should be gathered together into a common aggregate type, named "TopType", which will be declared in the Common Aggregate Types namespace. This type should be declared abstract, and all document headers should be extensions - even if only trivial extensions to facilitate re-naming - of this abstract type. (Note: This rule allows for polymorphic processing of the set of generic header elements across all document types.) [R 115b] All repeatable BIEs in the model will have generated containers. The containers will be named "[name_of_repeatable_element]List". These containers will be required if the cardinality of their contained immediate children requires at least one; if their contained children are optional; the container itself will be optional. At least one of the repeatable children of the List will always be required, but there may be more than one required child if that agrees with the cardinality found in the business model. All "_____List" elements will reference a "_______ListType", which will be declared in the same namespace as the element that represents the repeatable BIE in the business model. The content model of this type will have a single child element, which will have a maximum occurrence that reflects the maximum occurrence in the business model, and a minimum occurrence as described in this rule, above. (NOTE: This rule applies equally to 'list' containers at the document level, and also at lower levels within the document.)
		The document element in the schema will have a content model that is a sequence of elements, the first of which will be the "Top" element, and the others will be the generated "List" elements, in the order in which their contained, repeatable children appeared in the model.	[R 115c]
		All elements in the generated schema that are direct children of the generated "top" elements in all documents should be gathered together into a common aggregate type, named "TopType", which will be declared in the Common Aggregate Types namespace. This type should be declared abstract, and all document headers should be extensions - even if only trivial extensions to facilitate re-naming - of this abstract type. (Note: This rule allows for polymorphic processing of the set of generic header elements across all document types.)	[R 115d]
		UBL Schema MUST be constructed using the following pattern