Universal Business Language (UBL)Draft The root element MUST be the only global element declared in document schemas. Each dictionary entry name MUST define one and only one fully qualified path (FQP) for an element or attribute. Untestable UBL Libraries and Schemas MUST only use ebXML Core Component approved ccts:CoreComponentTypes, except in the case of extension, where the 'UBLExtensions' element is used. Fully-Testable Mixed content MUST NOT be used except where contained in an xsd:documentation element. MDC2: Mixed content MUST NOT be used except where contained in an xsd:documentation element. ]]>Fully-Testable All element declarations MUST be global ELD2: All element declarations MUST be global ]]>BH: This is a complex rule. This would be better handled with 2 rules.Fully-Testable The xsd:any element MUST NOT be used except within the 'ExtensionContentType' type definition, and with xsd:processContents= "skip" for non-UBL namespaces. GSX14: The xsd:any element MUST NOT be used except within the 'ExtensionContentType' type definitions xsd:processContents= "skip" for non-UBL namespaces. ]]>I am not sure I understand what this means. An example would make this more understandable. The 'UBL Extensions' element MUST be declared as the first child of the document element with xsd:minOccurs="0". I am not sure I understand what this means. An example would make this more understandable. The 'UBLProfileID' element MUST be declared immediately following the 'UBL Extensions' element with xsd:minOccurs="0".". I am not sure I understand what this means. An example would make this more understandable. The 'UBLSubsetID' element MUST be declared immediately following the 'UBLProfileID' element with xsd:minOccurs="0". Fully-Testable Every UBL-defined –or -used schema module, except internal schema modules, MUST have a namespace declared using the xsd:targetNamespace attribute. NMS1: Every UBL-defined –or -used schema module, except internal schema modules, MUST have a namespace declared using the xsd:targetNamespace attribute. ]]>Untestable without UBL library. Every UBL-defined-or -used major version schema set MUST have its own unique namespace. Untestable without list of UBL library. UBL namespaces MUST only contain UBL developed schema modules. NMS4 and NMS5 are identical. The namespace names for UBL Schemas holding committee draft status MUST be of the form: urn:oasis:names:tc:ubl:schema:<subtype>:<document-id> The namespace names for UBL Schemas holding OASIS Standard status MUST be of the form:urn:oasis:names:specification:ubl:schema:<subtype>:<document-id> Untestable UBL published namespaces MUST never be changed. This is only testable if you whether the schema is a committee draft.Fully-Testable Every UBL Schema and schema module major version committee draft MUST have an RFC 3121 document-id of the form Fully-Testable 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 [.<revision>] 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 ]]> Every UBL Schema and schema module major version OASIS Standard MUST have an RFC 3121 document-id of the form <name>-<major> 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 Every minor version release of a UBL schema or schema module committee draft MUST have an RFC 3121 document-id of the form Every minor version release of a UBL schema or schema module committee draft MUST capture its version information in the xsd:version attribute in the form Every minor version release of a UBL schema or schema module OASIS Standard MUST have an RFC 3121 document-id of the form 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 For UBL Minor version changes the namespace name MUST not change, UBL Schema and schema module minor version changes MUST not break semantic compatibility with prior versions. Every UBL Schema and schema module major version number MUST be a sequentially assigned, incremental number greater than zero. Every UBL Schema and schema module minor version number MUST be a sequentially assigned, incremental non-negative integer. Every UBL document schema MUST declare an optional element named "UBLVersionID" immediately following the optional 'UBL Extensions' element. Untestable UBL Schema expressions MAY be split into multiple schema modules. 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. 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. All UBL internal schema modules MUST be in the same namespace as their corresponding document schema. Each UBL internal schema module MUST be named {ParentSchemaModuleName}{InternalSchemaModuleFunction}{schema module} Untestable A UBL schema module MAY be created for reusable components. The UBL extensions schema module MUST be identified as CommonExtensionComponents in the document name within the schema header. Untestable A schema module defining all UBL Common Aggregate Components MUST be created. The UBL Common Aggregate Components schema module MUST be identified as CommonAggregateComponents in the document name within the schema header. The ubl:CommonAggregateComponents schema module MUST reside in its own namespace. The ubl:CommonAggregateComponents schema module namespace MUST be represented by the namespace prefix "cac" when referenced in other schemas. A schema module defining all UBL Common Basic Components MUST be created. The UBL Common Basic Components schema module MUST be identified as CommonBasicComponents in the document name within the schema header. The ubl:CommonBasicComponents schema module MUST reside in its own namespace. The ubl:CommonBasicComponents schema module namespace MUST be represented by the namespace prefix "cbc" when referenced in other schemas. The ccts:UnqualifiedDatatypes schema module namespace MUST be represented by the token "udt" when referenced in other schemas. A schema module defining all UBL Qualified Datatypes MUST be created. The UBL Qualified Datatypes schema module MUST import the ccts:UnQualifiedDatatypes schema module. The UBL Qualified Datatypes schema module MUST be identified as QualifiedDatatypes in the document name in the schema header. The ubl:QualifiedDatatypes schema module MUST reside in its own namespace. The ubl:QualifiedDatatypes schema module namespace MUST be represented by the namespace prefix "qdt" when referenced in other schemas. The CommonExtensionComponents schema module namespace MUST be represented by the namespace prefix 'ext' when referenced in other schemas. I don't understand the rationale for this requirement. This seems like a configuration issue and the possibility of schemas being out of sync is highly likely.Untestable UBL MUST provide two schemas for each transaction. One normative schema shall be fully annotated. One non-normative schema shall be a run-time schema devoid of documentation. There is an extra colon follwoing Version(mandatory): that should be deleted from the original document.An example in the full documentation would be really helpful.This rule could be fully testable if the mandatory and optional documentation components were separated into two rules. The mandatory components are testable.Partially-Testable 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): RepresentationTerm (mandatory) QualifierTerm(s) (mandatory, where used) UniqueIdentifier (mandatory) Usage Rule(s) (optional) Content Component Restriction (optional) [DOC1-1/4]: DictionaryEntryName (mandatory): 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): [DOC1-2/4]: Version (mandatory): 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): [DOC1-3/4]: RepresentationTerm (mandatory): 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): [DOC1-4/4]: UniqueIdentifier (mandatory): 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): ]]> 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. 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 Component. 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. 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. 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. 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. 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.Untestable UBL XML element and type names MUST be in the English language, using the primary English spellings provided in the Oxford English Dictionary. Untestable UBL XML element and type names MUST be consistently derived from CCTS conformant dictionary entry names. Test with spaces and periods. Non-W3CXML 1.0 XML Names should be picked up by the parser.Does this mean hypens (-) and underscores (_) are allowed?Fully-Testable 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. [GNR3]: Space Found: 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. [GNR3]: Period Found: 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. ]]>Untestable 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 maintained and published by the UBL TC. The acronyms and abbreviations listed in the UBL-approved list MUST always be used in place of the word or phrase they represent. Untestable UBL XML element, and type names MUST be in singular form unless the concept itself is plural. Untestable 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. Untestable Acronyms and abbreviations MUST appear in all upper case for all element declarations and type definitions. Untestable The UpperCamelCase (UCC) convention MUST be used for naming elements and types Cannot test without all schema's.Partially-Testable A UBL xsd:complexType name based on an ccts:AggregateBusinessInformationEntity MUST be the ccts:DictionaryEntryName with the separators removed and with the "Details" suffix replaced with "Type". [CNT1]: A UBL xsd:complexType name based on an ccts:AggregateBusinessInformationEntity MUST be the ccts:DictionaryEntryName with the separators removed and with the "Details" suffix replaced with "Type". ]]> A UBL xsd:complexType name based on a ccts:BasicBusinessInformationEntityProperty MUST be the ccts:DictionaryEntryName 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. 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. 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. 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. 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. 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. 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.. Fully-Testable All types MUST be named. [GTN1]: All types MUST be named. ]]>Fully-Testable The predefined XML Schema type xsd:anyType MUST NOT be used. [GTD2]: The predefined XML Schema type xsd:anyType MUST NOT be used. ]]>I am not sure what this is saying. I think it is saying for every global element that is not defined as an XSD datatype, then a complexType should be created. For every class identified in the UBL model, a named xsd:complexType MUST be defined. For every ccts:BBIEProperty identified in the UBL model a named xsd:complexType must be defined. This rule has to rely on the documentation in order to test.Partially-Testable Every ccts:ABIE xsd:complexType definition content model MUST use the xsd:sequence element containing references to the appropriate global element declarations. [CTD2]: Every ccts:ABIE xsd:complexType definition content model MUST use the xsd:sequence element containing references to the appropriate global element declarations. ]]>This rule has to rely on the documentation in order to test.Partially-Testable Every ccts:BBIEProperty xsd:complexType definition content model MUST use the xsd:simpleContent element. [CTD3]: Every ccts:BBIEProperty xsd:complexType definition content model MUST use the xsd:simpleContent element. ]]> Every ccts:BBIEProperty xsd:complexType content model xsd:simpleContent element MUST consist of an xsd:extension element. [CTD4]: Every ccts:BBIEProperty xsd:complexType content model xsd:simpleContent element MUST consist of an xsd:extension element. ]]>Untestable Every ccts:BBIEProperty xsd:complexType content model xsd:base attribute value MUST be the UN/CEFACT Unqualified Datatype or UBL Qualified Datatype as appropriate. Untestable For every Qualified Datatype used in the UBL model, a named xsd:complexType or xsd:simpleType MUST be defined. Untestable A ccts:QualifiedDataType MUST be based on an unqualified data type and add some semantic and/or technical restriction to the unqualified data type. Untestable 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. 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; (1) MUST be defined as an xsd:simpleType (2) MUST contain one xsd:restriction element (3) MUST include an xsd:base attribute that defines the specific XSD built-in data type required for the content component 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 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 For every class and property identified in the UBL model, a global element bound to the corresponding xsd:complexType MUST be declared. When a ccts:ASBIE is unqualified, it is bound via reference to the global ccts:ABIE element to which it is associated. When a ccts:ASBIE is qualified, a new element MUST be declared and bound to the xsd:complexType of its associated ccts:ABIE. The code list xsd:import element MUST contain the namespace and schema location attributes. Empty elements MUST not be declared, except in the case of extension, where the 'UBL Extensions' element is used. [ELD7]: Empty elements MUST not be declared, except in the case of extension, where the 'UBL Extensions' element is used. ]]>Untestable All UBL Codes MUST be part of a UBL or externally maintained Code List. Untestable The UBL Library SHOULD identify and use external standardized code lists rather than develop its own UBL-native code lists. Untestable 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. Untestable Built-in XSD Simple Types SHOULD be used wherever possible. 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"Fully-Testable The xsd:substitutionGroup feature MUST NOT be used. [GSX5]: The xsd:substitutionGroup feature MUST NOT be used. ]]> The xsd:final attribute MUST be used to control extensions where there is a desire to prohibit further extensions. xsd:notation MUST NOT be used. [GSX7]: xsd:notation MUST NOT be used. ]]> The xsd:all element MUST NOT be used. [GSX8]: The xsd:all element MUST NOT be used. ]]>This requires some human knowledge about the use of xsd:choice.Partially-Testable The xsd:choice element SHOULD NOT be used where customisation and extensibility are a concern. [GSX9]: The xsd:choice element SHOULD NOT be used where customisation and extensibility are a concern. ]]>You would need to know the schema is a code-list schema. Partially-Testable The xsd:union technique MUST NOT be used except for Code Lists. The xsd:union technique MAY be used for Code Lists. [GSX11]: The xsd:union technique MUST NOT be used except for Code Lists. The xsd:union technique MAY be used for Code Lists. ]]>The SHOULD NOT makes the rule optional.Partially-Testable UBL designed schema SHOULD NOT use xsd:appinfo. If used, xsd:appinfo MUST only be used to convey non-normative information. Untestable 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. Fully-Testable The built in xsd:nillable attribute MUST NOT be used for any UBL declared element. [GSX16]: The built in xsd:nillable attribute MUST NOT be used for any UBL declared element. ]]>Fully-Testable The xsd:anyAttribute MUST NOT be used. [GSX17]: The xsd:anyAttribute MUST NOT be used. ]]>Untestable Complex Type extension or restriction MAY be used where appropriate. Untestable All UBL instance documents MUST validate to a corresponding schema. Untestable in Schematron because you can't test against the XML declaration. All UBL instance documents MUST identify their character encoding within the XML declaration. Untestable in Schematron because you can't test against the XML declaration. In conformance with ISO IEC ITU UN/CEFACT eBusiness 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. This is an instance rule and not a schema rule.Untestable UBL conformant instance documents MUST NOT contain an element devoid of content or containing null values, except in the case of extension, where theUBLExtensionContent element is used. Untestable The absence of a construct or data in a UBL instance document MUST NOT carry meaning.