How UBL could postpone a decision about whether or not to implement the CLSC Codelist Schema Design

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

 

 

----- Original Message ----- 

  
From: 
  Stephen Green 

  
To:  

  
Sent: Friday, March 12, 2004 6:46 
PM

  
Subject: [ubl] Case that we can avoid 
  substitutionGroups now without precluding them for later

  

  

  
Case that we can avoid substitutionGroups now without precluding 
  them for later

  
 

  
Please find attached a proof of concept set of 
  Schemas

  
 

  
This uses the latest Schemas from Gefeg (1.0 
  draft 8.1) as a strarting point

  
 

  
I have added two different versions of the 
  currency codelist schema

  
- 
  UBL-CodeList-CurrencyCode-1.0-draft-8.1sdg.xsd   - this has no 
  substitutionGroups and represents what we could start with now 

  
- 
  UBL-CodeList-CurrencyCode-1.0-draft-8.1substitutionGroup.xsd - this has 
  substitutionGroups and represents what Marty is proposing but which I propose 
  deciding about say prior to UBL 1.1

  
 

  
UBL-CodeList-CurrencyCode-1.0-draft-8.1substitutionGroup.xsd   
  slightly differs from Marty's in that it has the sequence of Supplementary 
  Components we have in draft 8.1

  
and uses DerivedCode and DerivedCodeType as 
  names. It also has amended namespaces. Yet I believe it does not differ 
  substantially (functionally) from the CLSC version.

  
 

  
To use each of the above the name should be 
  changed of either to UBL-CodeList-CurrencyCode-1.0-draft-8.1.xsd but that is 
  all.

  
 

  
There are also included two samples of an 
  invoice, generated with XML Spy 2004 as maximal examples from each of the two 
  possible sets of Schemas and named accordingly.

  
 

  
Proof:

  
It is found that *each* instance validates 
  correctly against *each* Schema set version/configuration. There is 
  therfore both backwards and forwards compatibilty

  
when switching from our present draft 8.1 
  (without substitutionGroups) to a version

  
as proposed by CLSC *with* 
  substitutionGroups.

  
 

  
Conclusion:

  
It would be, I propose, completely feasible to 
  leave the codelist schemas without the S'Groups now for 1.0 and to defer a 
  decision till between 1.0 and 1.1

  
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) but to create in the

  
present format *without* s'Groups now knowing 
  that we can change it later. It would for many codelists now be empty (as with 
  our beta).

  
This would avoid our current situation of lack of 
  time for all to consider this thoroughly and to be happy with the CLSC 
  proposal.

  
(It might be noted that non-codelist enumeration 
  lists could be kept in the SDT and not

  
have codelist schema modules, 
  thereby allowing these to avoid the possibility of future 
  

  
encouragement to change them - i.e. changes to 
  such would require namespace changes too.) 

  
 

  
Thanks

  
 

  
Stephen Green

  
 

  

  

  

To unsubscribe from this mailing list (and be removed from the roster 
  of the OASIS TC), go to 
  http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.