ࡱ > q` ?{ bjbjqPqP . : : ?s
) $ 84 2 D Z Z Z Z Z h K M M M M M M $ h f q N Z Z N N q Z Z 2 2 2 N " Z Z K 2 N K 2 2 Z 8 pf! p 7 0 , > \ , 2 $ q q (
N N N N 84 84 84 T ܈ - 84 84 84 ܈ 0
UBL Naming and Design Rules
Draft P
Rule NumberRule[CDL1]All UBL Codes MUST be part of a UBL or External 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]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).[CDL5]All UBL maintained or used Code Lists MUST be enumerated using the UBL Code List schema module.[CDL6]The name of each UBL Code List schema module MUST be of the form:
{Owning Organization}[Code List Name}{Code List schema module}[CDL7]An xsd:Import element MUST be declared for every code list required in a UBL schema.[CDL8]Users of the UBL Library may identify any subset they wish from an identified code list for their own trading community conformance requirements.
Table A2. Constraint Rules
Rule NumberRule Modeling Constraints [Ed. Note deleted in Washington][MDC1]UBL Libraries and Schemas MUST only use ebXML Core Component approved ccts:CoreComponentTypes.[Ed. Note deleted in Washington][MDC2]Mixed content MUST NOT be used except where contained in an xsd:documentation element. Naming Constraints[NMC1]Each dictionary entry name MUST define one and only one fully qualified path (FQP) for an element or attribute.
Table A3 Declarations Rules
Rule NumberRuleElement Declarations[ELD1]Each UBL:ControlSchema MUST identify one and only one global element declaration that defines the document ccts:AggregateBusinessInformationEntity 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.
[ELD2]All element declarations MUST be global with the exception of ID and Code which MUST be local.[ELD3]For every class 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. When an ccts:ABIE is qualified, a new element MUST be declared and bound to the xsd:complexType of its associated ccts:AggregateBusinessInformationEntity.[ELD5]For each ccts:CCT simpleType, an xsd:restriction element MUST be declared.[ELD6]The code list xsd:import element MUST contain the namespace and schema location attributes.[ELD7]Empty elements MUST not be declared.[ELD8]The xsd:any element MUST NOT be used.Attribute Declarations[ATD1]User defined attributes SHOULD NOT be used. When used, user defined attributes MUST only convey CCT:SupplementaryComponent information.[ATD2]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.[ATD3]Within the ccts:CCT xsd:extension element an xsd:attribute MUST be declared for each ccts:SupplementaryComponent pertaining to that ccts:CCT.[ATD4]For each ccts:CCT simpleType xsd:Restriction element, an xsd:base attribute MUST be declared and set to the appropriate xsd:datatype.[ATD5]Each xsd:schemaLocation attribute declaration MUST contain a persistant and resolvable URL.[ATD6]Each xsd:schemaLocation attribute declaration URL MUST contain an absolute path.
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.
[ATD7]The xsd built in nillable attribute MUST NOT be used for any UBL declared element.[ATD8]The xsd:any attribute MUST NOT be used.[ATD11]The xsd:version attribute MUST be used to convey the version of the schema. Its value MUST be identical to the portion of the namespace declaration schema version information. The xsd:version attribute MUST NOT be considered normative if different from the version information contained in the namespace declaration. FIXTable A4. Documentation Rules
Rule NumberRule[DOC1] Every Data Type definition MUST contain a structured set of annotations in the following patterns:
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.
[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.
[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
[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.
DOC5Every 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.
DOC6Every 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.
DOC7Every 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.
[DOC8]Every element declaration MUST contain an annotation as follows:
Dictionary Entry Name where Dictionary Entry Name is the complete name (not the tag name) that is the unique official name of the element in the UBL library.[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.
Table A5. General XSD Rules
Rule NumberRule [GXS1]UBL Schema MUST conform to the following physical layout as applicable:
XML Declaration
Copyright ( 2001-2004 The Organization for the Advancement of Structured Information Standards (OASIS). All rights reserved.
xsd:schema element to include version attribute and namespace declarations in the following order:
xmlns:xsd
Target namespace
Default namespace
CommonAggregateComponents
CommonBasicComponents
CoreComponentTypes Datatypes
Identifier Schemes
Code Lists
Attribute Declarations elementFormDefault=qualified attributeFormDefault=unqualified
CommonAggregateComponents schema module
CommonBasicComponents schema module
Representation Term schema module (to include CCT module)
Common Basic Types schema module
Common Aggregate Types schema module
Global Attributes and Attribute Groups
Root Element Declaration
Root Element Type Definition
alphabetized order
All type definitions segregated by basic and aggregates as follows
alphabetized order of ccts:AggregateBusinessInformationEntity xsd:TypeDefinitions
alphabetized order of ccts:BasicBusinessInformationEntities
Required OASIS full copyright notice.[GXS2]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.[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:substitution groups feature MUST NOT be used.[GXS6]The xsd:final attribute MUST be used to control extensions.[GXS7]xsd:notations MUST NOT be used.[GXS8]The xsd:all element MUST NOT be used.[GXS9]The xsd:choice element MUST NOT be used.[GXS10]The xsd:include feature MUST only be used within a document schema.[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.
Table A6 Instance Documents
Rule NumberRule[IND1]All UBL instance documents MUST validate to a corresponding schema. [IND2]All UBL instance documents MUST always identify their character encoding with 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= HYPERLINK "http://www.w3.org/2001/XMLSchema-instance" http://www.w3.org/2001/XMLSchema-instance.[IND5]UBL conformant instance documents MUST NOTcontain an element devoid of content. [IND6]The absence of a construct or data in a UBL instance document MUST NOT carry meaning.Table A7 Naming Rules
Rule NumberRule 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.[GNR2]UBL XML element, attribute and type names MUST be consistently derived from CCTS conformant dictionary entry names.[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. [GNR4]UBL XML Element, attribute, 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.[GNR7]UBL XML element, attribute and type names MUST be in singular form unless the concept itself is plural (example: Goods).[GNR8]The UpperCamelCase (UCC) convention MUST be used for naming elements and types.[GNR9]The lowerCamelCase (LCC) convention MUST be used for naming attributes.Specific Naming RulesElement 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 an ccts:ASBIE MUST be declared and bound to the xsd:complexType of its associated ccts:ABIE.[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.Attribute Naming Rules[ATN1]Each CCT:SupplementaryComponent xsd:attribute name MUST be the ccts:SupplementaryComponent dictionary entry name property term and representation term, with the separators removed.Type Naming Rules[CTN1]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.[CTN2]
A UBL xsd:complexType name based on a ccts:BBIEProperty MUST be the ccts:DictionaryEntryName shared property term and qualifiers and representation term of the shared BBIE, with the separators removed and with the Type suffix appended after the representation term. [CTN3]A UBL xsd:complexType for acct:UnspecialisedDatatype used in the UBL model MUST have the name of the corresponding ccts:CoreComponentType, with the separators removed and with the Type suffix appended.[CTN4]A UBL xsd:complexType for a cct:UnspecialisedDatatype based on a ccts:SecondaryRepresentationTerm used in the UBL model MUST have the name of the corresponding ccts:SecondaryRepresentationTerm, with the separators removed and with the Type suffix appended.[CTN5]A UBL xsd:complexType name based on a ccts:CoreComponentType MUST be the Dictionary entry name of the ccts:CoreComponentType, with the separators removed.
Table A8 Namespace Rules
Rule NumberRule[NMS1]Every UBL defined or used schema module MUST have a namespace declared using the xsd:targetNamespace attribute.[NMS2]Every UBL defined or used schema set version 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:::[][NMS5]The namespace names for UBL Schemas holding OASIS Standard status MUST be of the form:
urn:oasis:names:specification:ubl:schema:::[NMS6]UBL Schema modules MUST be hosted under the UBL committee directory:
http://www.oasis-open.org/committees/ubl/schema/.xsd[NMS7]UBL published namespaces MUST never be changed. [NMS8]The UBL:CommonAggregateComponents schema module MUST reside in its own namespace.[NMS9]The ubl:CommonAggregateComponents schema module MUST be represented by the token cac.[NMS10]The UBL:CommonBasicComponents schema module MUST reside in its own namespace.[NMS11]The UBL:CommonBasicComponents schema module MUST be represented by the token cbc.[NMS12]The ccts:CoreComonentType schema module MUST reside in its own namespace.[NMS13]The ccts:CoreComponentType schema module namespace MUST be represented by the token cct.[NMS14]The ccts:UnspecialisedDatatype schema module MUST reside in its own namespace.[NMS15]The ccts:CodeTypeUnspecialisedDatatype schema module MUST reside in the ccts:UnspecialisedDatatype namespace.[NMS16]The ccts:UnspecialisedDatatype schema module namespace MUST be represented by the token udt.[NMS17]The ubl:SpecialisedDatatypes schema module MUST reside in its own namespace. [NMS18]The ubl:SpecialisedDatatypes schema module namespace MUST be represented by the token sdt.[NMS19]Each ubl:CodeList schema module MUST be maintained in a separate namespace.
Table A9 Root Element Declaration Rules
Rule NumberRule [RED1]Every UBL business document MUST have a single root element.[RED2]Every root element in a UBL document MUST be named according to the portion of the business process that it initiates.
Table A10 Schema Structure Modularity Rules
Rule NumberRule [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 UBL document schema in one UBL namespace that is dependent 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:CommonAggregateComponents MUST be created.[SSM10]The ubl:CommonAggregateComponents schema module MUST be named ubl:CommonAggregateComponents Schema Module[SSM11]A schema module defining all ubl:CommonBasicComponents MUST be created.
[SSM12]The ubl:CommonBasicComponents schema module MUST be named ubl:CommonBasicComponmnents Schema Module[SSM13]A schema module defining all ccts:CoreComponentTypes MUST be created.[SSM14]The ccts:CoreComponentType schema module MUST be named ccts:CoreComponentType Schema Module[SSM15]The xsd:facet feature MUST not be used in the ccts:CoreComponentType schema module.[SSM16
]
A schema module defining all ccts:UnspecialisedDatatypes with the exception of ccts:CodeTypeUnspecialisedDatatype MUST be created[SSM17]
A schema module defining the ccts:CodeType ccts:UnspecialisedDatatype MUST be created[SSM18]The ccts:UnspecialisedDatatype schema module MUST be named ccts:UnspecialisedDatatype Schema Module
[SSM19]The ccts:CodeTypeUnspecialisedDatatype schema module MUST be named ccts:CodeTypeUnspecialisedDatatype Schema Module[SSM20]A schema module defining all ubl:SpecialisedDatatypes MUST be created.[SSM21]The ubl:SpecialisedDatatypes schema module MUST be named ubl:SpecialisedDatatypes schema module
Table A11 Standards Adherence Rules
Rule NumberRule [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.
Table A12 Type Definition Rules
Rule NumberRuleGeneral Type Definitions[GTD1]All types MUST be named.[GTD2]The xsd:any Type MUST NOT be used.Simple Type Definitions[STD1]For every ccts:CCT whose supplementary components map directly onto the properties of a built-in xsd:datatype, the ccts:CCT MUST be defined as a named xsd:simpleType in the ccts:CCT schema module[STD2]Each ccts:CCT xsd:simpleType definition name MUST be the ccts:CCT dictionary entry name with the separators removed.[STD3]xsd:simpleType restriction MUST NOT be used for ccts:CCTs.[CTD1]For every class 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 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.[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 ccts:CCT of the unspecialised or specialised UBL datatype as appropriate.[CTD6]For every datatype used in the UBL model, a named xsd:complexType or xsd:simpleType MUST be defined.[CTD7]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..[CTD8]Each ccts:CCT xsd:complexType definition MUST contain one xsd:simpleContent element[CTD9]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.[CTD10]Each CCT:SupplementaryComponent xsd:attribute type MUST define the specific xsd:built-in Datatype or the user defined xsd:simpleType for the ccts:SupplementaryComponent of the ccts:CCT. [CTD11]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. [CTD12]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.[CTD15]Each ccts:Supplementary Component xsd:attribute use MUST define the occurrence of that ccts:SupplementaryComponent as either required, or optional..[CTD16]Each ccts:CCT simpleType definition name MUST be the ccts:CCT dictionary entry name with the separators removed.Table A13 Versioning Rules
Rule NumberRule [VER1]Every UBL Schema and schema module major version committee draft MUST have the URI of:
urn:oasis:names:tc:ubl:schema:::0:[][VER2]Every UBL schema and schema module major version OASIS Standard MUST have the URI of:
urn:oasis:names:specification:ubl:schema:::0[VER3]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::::[][VER4]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[VER5]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.[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 number.[VER8]Each UBL minor version MUST be given a separate namespace.[VER9]A UBL minor version document schema MUST import its immediately preceding minor version document schema.[VER10]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. [VER11]UBL Schema and schema module minor version changes MUST not break semantic compatibility with prior versions.
% 0 1 7
o
p
v | x ~ / 5 \ b 3 9 R Y " " T( Y( c- h- 3 3 7 7 8 8 9 9 =: >: ? ? yF zF F F F j/7 h h Uj h h U j h h *h h *h h *h h 5 h h 5h h D $ % 1 6 7 > T kd $$If 4 0 W," A G 0 6 4 4
l a f4p $If gd gd gd gd ?{ } } $If gd x kd $$If 4 0 W," A G 0 6 4 4
l a f4 } } $If gd x kd $$If 4 0 W," A G 0 6 4 4
l a f4
} } $If gd x kd $$If 4 0 W," A G 0 6 4 4
l a f4
} } $If gd x kd $$If 4 0 W," A G 0 6 4 4
l a f4 " d } } } $If gd x kdY $$If 4 0 W," A G 0 6 4 4
l a f4 } } $If gd x kd- $$If 4 0 W," A G 0 6 4 4
l a f4 } } $If gd x kd $$If 4 0 W," A G 0 6 4 4
l a f4 x x $If gd gd x kd $$If 4 0 W," A G 0 6 4 4
l a f4 n e $If gd kd $$If 4 0 W," A G 0 6 4 4
l a f4p
$If gd e kd $$If 4 ," 0 6 4 4
l a f4
n
$If gd v kdA $$If 4 0 W," A G 0 6 4 4
l a f4 n
o
p
$If gd v kd
$$If 4 0 W," A G 0 6 4 4
l a f4
$If gd v kd
$$If 4 0 W," A G 0 6 4 4
l a f4
c kd} $$If 4 ," 0 6 4 4
l a f4 $If gd v kd $$If 4 0 W," A G 0 6 4 4
l a f4 { { gd v kd
$$If 4 0 W," A G 0 6 4 4
l a f4 $If gd n e $If gd kd
$$If 4 0 p," O 9 0 6 4 4
l a f4p $If gd c kd $$If 4 ," 0 6 4 4
l a f4 $If gd v kdx $$If 4 0 p," O 9 0 6 4 4
l a f4 u $If gd v kdL $$If 4 0 p," O 9 0 6 4 4
l a f4 u v } ~ w $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 w x $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 . $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 . / 6 [ $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 [ \ c $If gd v kdp $$If 4 0 p," O 9 0 6 4 4
l a f4 c kd $$If 4 ," 0 6 4 4
l a f4 $If gd v kdD $$If 4 0 p," O 9 0 6 4 4
l a f4 2 3 : v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 $If gd $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 9 $If gd v kdT $$If 4 0 p," O 9 0 6 4 4
l a f4 9 : ; < $If gd v kd( $$If 4 0 p," O 9 0 6 4 4
l a f4 < = > ? $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 ? @ G $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 $If gd v kd $$If 4 0 p," O 9 0 6 4 4
l a f4 $If gd v kdx $$If 4 0 p," O 9 0 6 4 4
l a f4 } } $If gd x kdL $$If 4 0 p," O 9 0 6 4 4
l a f4 $ i } } $If gd x kd% $$If 4 0 p," O 9 0 6 4 4
l a f4 i j x x $If gd gd x kd $$If 4 0 p," O 9 0 6 4 4
l a f4 y : w P l c c c c c c c c c c $If gd kd $$If 4 0 Y," B F 0 6 4 4
l a f4p P Q R Y m s kd $$If 0 Y," B F 0 6 4 4
l a $If gd ! ! ! ! $If gd v kd! $$If 4 0 Y," B F 0 6 4 4
l a f4 ! " " " # ~# # K$ $ |% &