How UBL could postpone a decision about whether or not to implement the

ubl message

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

From: "Stephen Green" <stephen_green@seventhproject.co.uk>

To: <ubl@lists.oasis-open.org>

Date: Sun, 14 Mar 2004 15:41:55 -0000

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: ubl@lists.oasis-open.org

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.