Changes Requested
(1) The Codelist Schema
Modules should be treated as being Specialised DataType
Schema Modules. They are to remain as separate
Codelist Schema Modules but
the existing Specialised DataTypes Schema
Module will no longer be used to reference
the Codelist Schema Modules. Instead it will be
almost empty (similar to how it was in beta
as the 'DataTypes Schema Module'). I would
predict it looking like this (if it is generated for draft 8):
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4"
xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4"
xmlns="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1:0-draft-8.4">
<xsd:import
namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4"
schemaLocation="UBL-CoreComponentParameters-1.0-draft-8.4.xsd"/>
</xsd:schema>
[with the usual UBL Header comment block
too]
or, if Tim releases his draft 9 very soon, like
this:
<xsd:schema
targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-9.1"
xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-9.1"
xmlns="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-9.1"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1:0-draft-9.1">
<xsd:import
namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-9.1"
schemaLocation="UBL-CoreComponentParameters-1.0-draft-9.1.xsd"/>
</xsd:schema>
[In the following examples I'll just
keep to the draft-8.4 scenario.]
(2) This Specialised
DataTypes Schema Module will only need to be imported into the
Common Basic Components Schema Modules.
This is because the Code and Identifier BBIEs are the only ones declared outside of the
CBC Schema and of these two types the only relevant one is likely to be code
which has its specialised datatypes defined in
the separate codelist schema modules (a special type of SDT Schema) and not
now in the 'Specialised DataTypes Schema Module'.
(3) The 'use'
subfolder within the 'codelist' folder is to be dropped and all the codelists
schema modules just placed in the 'codelist' folder
(4) With the change in the
non-codelist SDT Schema Module in (1) above, the other Schema Modules
will
need to reference the Codelist Schema Modules
directly, i.e.:
targetNamespace="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4"
xmlns:res="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-draft-8.4"
...
xmlns:cur="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4"
xmlns:sdt="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4"
xmlns:udt="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4"
xmlns:cbc="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4"
xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4"
xmlns="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1:0-draft-8.4"<xsd:import
namespace="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4"
schemaLocation="../codelist/UBL-CodeList-CurrencyCode-1.0-draft-8.4.xsd"/>
...
<xsd:import
namespace="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-draft-8.4"
schemaLocation="../codelist/UBL-CodeList-AcknowledgementResponseCode-1.0-draft-8.4.xsd"/>
<xsd:import
namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4"
schemaLocation="UBL-CoreComponentParameters-1.0-draft-8.4.xsd"/>
<xsd:import
namespace="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4"
schemaLocation="UBL-CommonBasicComponents-1.0-draft-8.4.xsd"/>
<xsd:import
namespace="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4"
schemaLocation="UBL-UnspecialisedDatatypes-1.0-draft-8.4.xsd"/>
(5) The mention of
DerivedCodeType is to change to xxxxxCodeType where xxxxx is the Property Term
of the CodeList
e.g. cur:DerivedCodeType becomes
cur:CurrencyCodeType
(in future, external groups might be defining
their own names for these codelist schema modules but we will stick to using
the property from the SDT model)
(6) Note that since
the Codelist Schema Modules are now considered to be a kind of Specialised
DataType Schema Module and that the module
called the Specialised DataType Schema Module (of
which in future there could be many incidentally) is almost empty in UBL 1.0,
the reference
to the type of a code having a codelist schema
module from within the CommonAggregateComponents Schema Module or, where
required,
a Document Schema Module will look not like
sdt:DerivedCodeType or sdt:CurrencyCodeType
but for the example of the currency code like this:
<xsd:element name="CurrencyCode"
type="cur:CurrencyCodeType"
minOccurs="0">
<xsd:annotation>
<xsd:documentation>
...
(7) Not, I think, a
change request but more a note: In beta, the credits for codelist schemas
defined in the codelist spreadsheet (now the SDT spreadsheet)
were added to the UBL comment header block. Now
they won't appear at all in the Schemas (as, I believe they don't anyway) but
will just be held in the
spreadsheets.
(8) Again, not a
change request but a note, since you've already started implementing it:
The codes will all be based, not on the cct:CodeType but on
the
udt:CodeType (thanks)
(9) The 'names'
for codes from the codelists (the second string from the code text
file) should appear in some way in annotation/documentation
associated
with the 'value' enumeration in
the Codelist Schema Module.
e.g.
<xsd:element name="CurrencyCode"
type="CurrencyCodeType"/>
<xsd:complexType
name="CurrencyCodeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Instance>
<ccts:Prefix>cur</ccts:Prefix>
<ccts:CodeListQualifier>ISO
4217</ccts:CodeListQualifier>
<ccts:CodeListAgency>6</ccts:CodeListAgency>
<ccts:CodeListVersion>0.3</ccts:CodeListVersion>
</ccts:Instance>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction
base="udt:CodeType">
<xsd:enumeration
value="ADP">
...
<xsd:enumeration
value="USD">
<xsd:annotation>
<xsd:documentation>
<CodeName>United
States
Dollar</CodeName>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
...
<xsd:attribute name="name" type="xsd:string"
use="optional"/>
<xsd:attribute name="codeListID"
type="xsd:normalizedString"
use="optional"/>
<xsd:attribute
name="codeListAgencyID" type="xsd:normalizedString"
use="optional"/>
<xsd:attribute
name="codeListAgencyName" type="xsd:string"
use="optional"/>
<xsd:attribute name="codeListName"
type="xsd:string" use="optional"/>
<xsd:attribute
name="codeListVersionID" type="xsd:normalizedString"
use="optional"/>
<xsd:attribute name="codeListURI"
type="xsd:anyURI" use="optional"/>
<xsd:attribute
name="codeListSchemeURI" type="xsd:anyURI"
use="optional"/>
<xsd:attribute name="languageID"
type="xsd:language"
use="optional"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
I'm not sure in this example whether you'd use
this same element <CodeName> . In the CLSC example
an undefined prefix is hinted at but I think we
have yet to see how things turn out with the issues around
the use of the Core Components Parameters Schema
Module - whether an element defined there might
be suitable. For now I'd suggest sticking with
<CodeName> without a prefix unless you've a better idea.
(10) I was asked to
correct my e-mail bug report concerning DateType - I wrote cct:DateType; it
should of course read udt:DateType
and the udt:DateType should be based on the
xsd:date (a secondary representation term interpreting a udt:Date as an
xsd:date just as
UBL has a udt:Time as based on an
xsd:time).
<xsd:complexType
name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date.
Type</ccts:DictionaryEntryName>
<ccts:Definition>A
particular point in the progression of time together with the relevant
supplementary
information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="cct:DateTimeType"/>
</xsd:simpleContent>
</xsd:complexType>
should be
<xsd:complexType
name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date.
Type</ccts:DictionaryEntryName>
<ccts:Definition>A
particular point in the progression of time together with the relevant
supplementary
information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="udt:DateType"/>
</xsd:simpleContent>
</xsd:complexType>
So the fixes should then be made to the
Unspecialised DataType Schema Module, according to UBL's longstanding
NDR-endorsed exception to
the udt based on cct rule, such that
<xsd:complexType
name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date.
Type</ccts:DictionaryEntryName>
<ccts:Definition>A
particular point in the progression of time together with the relevant
supplementary
information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="cct:DateTimeType"/>
</xsd:simpleContent>
</xsd:complexType>
should become
<xsd:complexType
name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date.
Type</ccts:DictionaryEntryName>
<ccts:Definition>A
particular point in the progression of time together with the relevant
supplementary
information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="xsd:date"/>
</xsd:simpleContent>
</xsd:complexType>
and
<xsd:complexType
name="TimeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Time.
Type</ccts:DictionaryEntryName>
<ccts:RepresentationTerm>Time</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="cct:DateTimeType"/>
</xsd:simpleContent>
</xsd:complexType>
should become
<xsd:complexType
name="TimeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Time.
Type</ccts:DictionaryEntryName>
<ccts:RepresentationTerm>Time</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="xsd:time"/>
</xsd:simpleContent>
</xsd:complexType>
(11) Not
sure what the root of this problem was but there should be no more code
types like 4461_ Code. Type;
all should be replaced with their text
equivalents e.g. PaymentMeansCode. Type .
I'm not sure if this is a model
issue
though.