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.