|
How UBL could postpone a decision about
whether or not to implement the CLSC Codelist Schema
Design
Key point: It is not necessary to do
anything to change UBL 1.0 draft 8.1 ( a version without the abstract head
elements and
substitutionGroups ) in order to make it
possible to accommodate substitutionGroups later, if the latter were later
agreed.
Actually I can even withdraw my previous
qualification to this where I reported that "There would be a requirement to create
a Codelist Schema Module
for each codelist for which we might wish to
leave room for s'Groups later (if agreed)." I have
since found that we
need *not* change such things (at least, not for the
purpose of allowing the future ability to accommodate
the CLSC design) and
we could therefore defer all such considerations and possible changes
to a later decision.
How it could work:
1. Most codes in our existing 1.0 draft 8.1
Document and CAC Schema Modules have type udt:CodeType, whilst some
have
type
sdt:xxxxCodeType
2. Changes to the Specialised DataTypes
Schema Module to take us from without substitutionGroups to with
SubstitutionGroups
(and with abstract head
elements) can be controlled so as to have no effect on instance documents
(except where an actual
code value in the
document has since been removed, of course).
- see previous
message (below).
The controls
neccessary for this mainly concern preserving the Supplementary Components
included, their names, xsd:datatypes
and sequence.
3. As in 2. above, provided that the
Supplementary Components and their names, xsd:datatypes and sequence are preserved between
the Unspecialised DataType
Schema Module and the Specialised DataType Schema Module (as they are in UBL 1.0
draft 8.1),
changing the type of a
Code BBIE in a Document Schema Module or Common Aggregate Types Schema Module
from udt:CodeType
to sdt:xxxxCodeType has
*no* unwanted effect on the backwards compatibility of a
document instance before and after this change
(except, of
course, in the restricting of the code values).
4. The combined effects of 2. and 3. are
therefore acceptable for backwards compatibilty such that a 1.0 set of Schemas
*without*
substitution groups ( as
we have in UBL 1.0 draft 8.1 ) does not preclude the possibility of moving
later, with backwards compatibilty, to
a new minor version
*with* substitution groups and abstract head elements as
we have in the CLSC design proposal.
Examples
(using our XML Spy generated example instance) -
<InvoiceTypeCode name="String"
codeListID="normalizedString" codeListAgencyID="normalizedString"
codeListAgencyName="String" codeListName="String"
codeListVersionID="normalizedString" codeListURI="http://www.altova.com" codeListSchemeURI="http://www.altova.com"
languageID="en-us">normalizedString</InvoiceTypeCode>
would be equally valid against:
<xsd:element name="InvoiceTypeCode"
type="udt:CodeType"
minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>BBIE</ccts:CategoryCode>
<ccts:DictionaryEntryName>Invoice.
Invoice Type.
Code</ccts:DictionaryEntryName>
<ccts:Definition>identifies
the type of the Invoice by a
code.</ccts:Definition>
<ccts:ObjectClass>Invoice</ccts:ObjectClass>
<ccts:PropertyTerm>Invoice
Type</ccts:PropertyTerm>
<ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
<ccts:DataType>Code.
Type</ccts:DataType>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
as against:
<xsd:element name="InvoiceTypeCode"
type="sdt:xxxxCodeType"
minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>BBIE</ccts:CategoryCode>
<ccts:DictionaryEntryName>Invoice.
Invoice Type.
Code</ccts:DictionaryEntryName>
<ccts:Definition>identifies
the type of the Invoice by a
code.</ccts:Definition>
<ccts:ObjectClass>Invoice</ccts:ObjectClass>
<ccts:PropertyTerm>Invoice
Type</ccts:PropertyTerm>
<ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
<ccts:DataType>xxxxCode.
Type</ccts:DataType>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
This is because the type is essentially hidden
sufficiently from the instance (hidden in its
prefix and namespace, though not in its structure,
etc).
As long as both the udt:CodeType and sdt:xxxxCodeType have a similar enough structure
like
in the UDT Schema Module:
<xsd:complexType
name="CodeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Code.
Type</ccts:DictionaryEntryName>
<ccts:Definition>A
character string (letters, figures or symbols) that for brevity and/or language
independence may be used to represent or replace a definitive value or text of
an Attribute together with relevant supplementary information. Date Time. Type
Identifier.
Ty</ccts:Definition>
<ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction
base="cct:CodeType">
<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>
in the SDT Schema Module:
<xsd:complexType
name="CurrencyCodeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Currency_
Code.
Type</ccts:DictionaryEntryName>
<ccts:Definition>A
character string (letters, figures or symbols) that for brevity and/or language
independence may be used to represent or replace a definitive value or text of
an Attribute together with relevant supplementary information. Date Time. Type
Identifier.
Ty</ccts:Definition>
<ccts:QualifierRepresentationTerm>Currency</ccts:QualifierRepresentationTerm>
<ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension
base="cur:DerivedCodeType"/>
</xsd:simpleContent>
</xsd:complexType>
and in the Codelist Schema Module something
like:
<xsd:element name="DerivedCode"
type="DerivedCodeType"/>
<xsd:complexType
name="DerivedCodeType">
<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="cct:CodeType">
<xsd:enumeration
value="ADP"/>
...
<xsd:enumeration
value="ZWD"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
then there is no undesirable impact on the
instances when switching between udt: and sdt:xxxx
Likewise, the same Supplementary Component
structure would have to be preserved in the
proposed CLSC Codelist Schema Module design with
its substutionGroup
i.e. something like:
<xsd:element name="CurrencyCodeA"
type="xsd:normalizedString" abstract="true"/>
<xsd:simpleType
name="CurrencyCodeContentType">
<xsd:restriction
base="xsd:normalizedString">
<xsd:enumeration
value="ADP"/>
...
<xsd:enumeration
value="ZWD"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType
name="DerivedCodeType">
<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:extension
base="CurrencyCodeContentType">
<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:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:attribute
name="CurrencyCode" type="CurrencyCodeContentType"/>
<xsd:attribute
name="listID" type="xsd:normalizedString" fixed="ISO
4217"/>
<xsd:attribute name="listAgencyID" type="xsd:token"
fixed="6"/>
<xsd:attribute name="listVersionID" type="xsd:string"
fixed="0.3"/>
<xsd:element name="CurrencyCode" type="DerivedCodeType"
substitutionGroup="CurrencyCodeA"/>
then the combined effects of 2. and 3. do not break
backwards compatibilty:
One can add later both specialised code datatype schema modules where there were none
before
(without breaking backwards compatibility of
instances, apart from in their code values of course)
*and* at the same time not make it
impossible to add, then or later, the CLSC codelist schema design.
Conclusion
Therefore a 1.0 without the
substitutionGroup and abstract head element would not prevent
any future introduction of
substitutionGroup and abstract head element, if that were
agreed.
we could therefore defer all such
changes to a later decision (e.g. prior to a UBL
1.1)
Many thanks
Stephen Green
This thread already has a best answer. Would you like to mark this message as the new best answer?
|