RE: extending enumerated lists with xsd:union

Priscilla,

 

Thanks for the further comments. I have done some additional work paying better attention to rules for substitutions and derived the following solutions.

 

The results are attached, but I will summarize the rules I used:

 

In the code list schema:

1) Define a generic code list type based on xsd:normalized string and that contain all the supplementary components as attributes.

2) Declare a global element to represent the substitution head of this type with a trailing "H" to indicate it is the head of the substitution group.

3) Make a second global element that is a substitution for this head type that contains the actual codes and "fixes" the values of the supplementary components so they have the version information in them.

 

In the intermediate schema that uses code lists:

1) Declare code list carrying components as global elements of type "generic code list" and append the letter "H" to indicate a header element.

2) Declare a substitute for this header element that defines the specific code list to be used.

 

In the customizing schema:

1) Make a global element that is a substitution for the substitution head (which is based on the generic code list type.

2) Define the new codes only as a restriction in this global element.

 

In the instance document:

1) If you want to use the standard code values, use the standard list element name and corresponding values.

2) If you want to use the customized code values, use the extension schema prefix and the element name and corresponding values.

All the best,

Marty

? burnsmarty@a... '  +1(301(315-9101È+1(301)257-9101

 

Some schema snippets:

 

Generic Code List

 <!--
 Code list base class
-->
 <xsd:complexType name="CodeListType">
  <xsd:annotation>
   <xsd:documentation>
    <ccts:Component>
     <ccts:ComponentType>DT</ccts:ComponentType>
     <ccts:DictionaryEntryName> Code. Type</ccts:DictionaryEntryName>
     <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
     <ccts:DataTypeQualifier/>
     <ccts:DataType>Code. Type</ccts:DataType>
    </ccts:Component>
   </xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
   <xsd:extension base="xsd:normalizedString">
    <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="name" type="xsd:string" use="optional"/>
    <xsd:attribute name="languageID" type="xsd:language" use="optional"/>
    <xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional"/>
    <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" use="optional"/>
   </xsd:extension>
  </xsd:simpleContent>
 </xsd:complexType>

Code List Containing type

 <xsd:complexType name="CurrencyCodeType">
  <xsd:annotation>
   <xsd:documentation>
    <ccts:Component>
     <ccts:ComponentType>DT</ccts:ComponentType>
     <ccts:DictionaryEntryName>Currency_ Code. Type</ccts:DictionaryEntryName>
     <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
     <ccts:DataTypeQualifier>Currency</ccts:DataTypeQualifier>
     <ccts:DataType>Code. Type</ccts:DataType>
    </ccts:Component>
    <ccts:Instance>
     <ccts:CodeListID>ISO 4217 Alpha</ccts:CodeListID>
     <ccts:CodeListAgencyID>6</ccts:CodeListAgencyID>
     <ccts:CodeListAgencyName>United Nations Economic Commission for Europe</ccts:CodeListAgencyName>
     <ccts:CodeListName>Currency</ccts:CodeListName>
     <ccts:CodeListVersionID>0.3</ccts:CodeListVersionID>
     <ccts:CodeListURI>http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc</ccts:CodeListURI>
     <ccts:CodeListSchemeURI>urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0</ccts:CodeListSchemeURI>
     <ccts:LanguageID>en</ccts:LanguageID>
    </ccts:Instance>
   </xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
   <xsd:restriction base="CodeListType">
    <xsd:enumeration value="AED">
     <xsd:annotation>
      <xsd:documentation>
       <CodeName>Dirham</CodeName>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="AFN">
     <xsd:annotation>
      <xsd:documentation>
       <CodeName>Afghani</CodeName>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="ALL">
     <xsd:annotation>
      <xsd:documentation>
       <CodeName>Lek</CodeName>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="AMD">
     <xsd:annotation>
      <xsd:documentation>
       <CodeName>Dram</CodeName>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="ANG">
     <xsd:annotation>
      <xsd:documentation>
       <CodeName>Netherlands Antillian Guilder</CodeName>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="AOA">
     <xsd:annotation>
      <xsd:documentation>
       <CodeName>Kwanza</CodeName>
      </xsd:documentation>
     </xsd:annotation>
    </xsd:enumeration>
    <xsd:attribute name="codeListID" type="xsd:normalizedString" use="optional" fixed="ISO 4217 Alpha"/>
    <xsd:attribute name="codeListAgencyID" type="xsd:normalizedString" use="optional" fixed="6"/>
    <xsd:attribute name="codeListAgencyName" type="xsd:string" use="optional" fixed="United Nations Economic Commission for Europe"/>
    <xsd:attribute name="codeListName" type="xsd:string" use="optional" fixed="Currency"/>
    <xsd:attribute name="codeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/>
    <xsd:attribute name="name" type="xsd:string" use="optional"/>
    <xsd:attribute name="languageID" type="xsd:language" use="optional" fixed="en"/>
    <xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional" fixed="http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc%22/>
    <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" use="optional" fixed="urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0"/>
   </xsd:restriction>
  </xsd:simpleContent>
 </xsd:complexType>

Substitution Group header and substitutable type

 <xsd:element name="CurrencyCodeH" type="CodeListType"/>
 <xsd:element name="CurrencyCode" type="CurrencyCodeType" substitutionGroup="CurrencyCodeH"/>

Schema using code lists (this from UBL-Order

 <xsd:element name="PricingCurrencyCodeH" type="cur:CodeListType"/>
 <xsd:element name="PricingCurrencyCode" type="cur:CurrencyCodeType" substitutionGroup="PricingCurrencyCodeH">
  <xsd:annotation>
   <xsd:documentation>
    <ccts:Component>
     <ccts:ComponentType>BBIE</ccts:ComponentType>
     <ccts:DictionaryEntryName>Order. Pricing Currency. Code</ccts:DictionaryEntryName>
     <ccts:Definition>the currency in which all pricing on the transaction will be specified.</ccts:Definition>
     <ccts:Cardinality>0..1</ccts:Cardinality>
     <ccts:ObjectClass>Order</ccts:ObjectClass>
     <ccts:PropertyTerm>Pricing Currency</ccts:PropertyTerm>
     <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
     <ccts:DataType>Currency_ Code. Type</ccts:DataType>
    </ccts:Component>
   </xsd:documentation>
  </xsd:annotation>
 </xsd:element>

Customizing schema

 <xsd:element name="PricingCurrencyCode" substitutionGroup="PricingCurrencyCodeH">
  <xsd:complexType>
   <xsd:simpleContent>
    <xsd:restriction base="cur:CodeListType">
     <xsd:enumeration value="FQD">
      <xsd:annotation>
       <xsd:documentation>Free Iraqui Dollar</xsd:documentation>
      </xsd:annotation>
     </xsd:enumeration>
     <xsd:attribute name="codeListID" type="xsd:normalizedString" use="optional" fixed="myUBL"/>
     <xsd:attribute name="codeListAgencyID" type="xsd:normalizedString" use="optional" fixed="Z"/>
     <xsd:attribute name="codeListAgencyName" type="xsd:string" use="optional" fixed="HYPERTEK"/>
     <xsd:attribute name="codeListName" type="xsd:string" use="optional" fixed="Currency"/>
     <xsd:attribute name="codeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.00001"/>
     <xsd:attribute name="languageID" type="xsd:language" use="optional" fixed="en"/>
     <xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional" fixed="http://try.and.find.it>
     <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" use="optional" fixed="urn:my:UBL"/>
    </xsd:restriction>
   </xsd:simpleContent>
  </xsd:complexType>
 </xsd:element>

Instance Document use of types

Standard:

    <PricingCurrencyCode>AED</PricingCurrencyCode>

 

Custom:

     <myUBL:PricingCurrencyCode>FQD</myUBL:PricingCurrencyCode>

 

 

 

-----Original Message-----
From: Priscilla Walmsley [mailto:pwalmsley-lists@d...]
Sent: Wednesday, August 10, 2005 2:44 PM
To: 'Stephen Green'; xml-dev@l...
Subject: RE: extending enumerated lists with xsd:union

 

Hi Stephen,

 

I can see that it is tempting to use substitution groups (or some other

schema extension mechanism) for versioning, but I have found that it just

adds too much complexity. 

 

At a former client of mine (GS1 formerly known as EAN/UCC) we debated about

this too (both in the context of versioning and extending code lists for

different contexts).  We finally ended up putting every code list in a

separate schema document (just like UBL does) and creating an entirely new

type definition (with the same name) for each version of a code list. If you

wanted to change to a different version of a code list you would just swap

out the schema document.  Minor versions are backward compatible (also like

UBL, I think) but that is just enforced by the designers, not any particular

schema feature.

 

As far as extensibilty, one approach I have seen at another client is to

make the base type a union of some specific values and xs:token, then

restrict that:

 

Base Type:

<xs:simpleType name="TransactType">

 <xs:union memberTypes="xs:token">

  <xs:simpleType>

   <xs:restriction base="xs:token">

    <xs:enumeration value="A"/>

    <xs:enumeration value="B"/>

   </xs:restriction>

  </xs:simpleType>

 </xs:union>

</xs:simpleType> 

 

 

<xs:simpleType name="MyTransactType">

 <xs:restriction base="TransactType">

  <xs:enumeration value="A"/>

  <xs:enumeration value="B"/>

  <xs:enumeration value="C"/>

 </xs:restriction>

</xs:simpleType>

 

Of course, you have very little control, and the values in the base type are

suggestions more than anything. 

 

Hope that helps,

Priscilla

 

-----------------------------------------------------------------

Priscilla Walmsley                 http://www.datypic.com

Author, Definitive XML Schema     (Prentice Hall PTR)

        Definitive XQuery (coming in 2006)

-----------------------------------------------------------------

 

 

> -----Original Message-----

> From: Stephen Green [mailto:stephen_green@s...]

> Sent: Tuesday, August 09, 2005 4:38 AM

> To: xml-dev@l...

> Subject: Re: extending enumerated lists with xsd:union

>

> Priscilla

>

> Many thanks for this. It looks unlikely then that

> we will get codelist schemas which are extensible

> using derivation. As Marty Burns has asked, we'd

> appreciate any ideas for alternatives but we have

> of course considered that redeclaration of an

> entire new set of schemas without a trail, as it

> were, of derivation (polymorphism-like) may be

> necessary for codelists (as has been our fall-back

> strategy for UBL 1.0).

>

> I personally would like to see substitution groups

> used to create minor version schemas from previous

> sets of major or minor schemas to provide the 'audit

> trail' as it were, though I accept that this complicates

> things somewhat. We have looked at the mechanism

> (substitution groups without using abstracts) but not

> made a decision yet and part of the discussion now

> is how it might be applied to codelists. As an interim

> plan we aim to make it possible for anyone to extend

> our next version schemas (2.0) in this way, though we

> remain to decide whether to do so ourselves for minor

> versions. Others may wish to use this inheritance

> mechanism to customise our schemas but, though

> we'd like to ensure this is possible (with all global

> elements as well as types), we haven't decided whether

> to recommend it.

>

> Thanks again

>

> All the best

>

> Stephen Green

>

>

> ----- Original Message -----

> From: "Priscilla Walmsley" <pwalmsley-lists@d...>

> To: "'Stephen Green'" <stephen_green@s...>;

> <xml-dev@l...>

> Sent: Monday, August 08, 2005 2:22 PM

> Subject: RE: extending enumerated lists with xsd:union

>

>

> > Hi Stephen,

> >

> > Union is not considered "derivation" for the purposes of

> substitution

> > groups.  But your example is more complex than that.  You've got (at

> least)

> > two simple times: S1 (the original currency code list) and

> S2 (your union

> of

> > the original with new values.) Then you've got (at least)

> two complex

> types:

> > C1 that uses S1 for its simple content, and C2 that uses S2

> for its simple

> > content.  C2 would not be considered to be derived from C1

> just by virtue

> of

> > the fact that its content type is "derived by union" from

> C1's content

> type.

> > This would be true whether you were using union or even simple

> restriction.

> >

> >

> > If your goal is to version the UBL schemas, have you considered just

> > creating an entirely new set of schemas with no relation to

> the previous

> > version?  (And attempting to control backward compatibility in other

> ways.)

> >

> > Hope that helps,

> > Priscilla

> >

> > -----------------------------------------------------------------

> > Priscilla Walmsley                 http://www.datypic.com

> > Author, Definitive XML Schema     (Prentice Hall PTR)

> >         Definitive XQuery (coming in 2006)

> > -----------------------------------------------------------------

> >

> >

> > > -----Original Message-----

> > > From: Stephen Green [mailto:stephen_green@s...]

> > > Sent: Monday, August 08, 2005 8:37 AM

> > > To: xml-dev@l...

> > > Subject: extending enumerated lists with xsd:union

> > >

> > > Greetings xml-dev

> > >

> > > I've been looking at a way to use xsd:union to extend

> > > a list of enumerated values (a codelist in this case) as

> > > follows:

> > >

> > > <xsd:schema

> > > xmlns="urn:oasis:names:prototype:ubl:schema:xsd:CurrencyCode-2.1"

> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"

> > > targetNamespace="urn:oasis:names:prototype:ubl:schema:xsd:Curr

> > > encyCode-2.1"

> > > xmlns:cur="urn:un:unece:uncefact:codelist:draft:54217:2001"

> > > xmlns:ccts="urn:oasis:names:draft:ubl:schema:xsd:CoreComponent

> > > Parameters-1.1

> > > "

> > > elementFormDefault="qualified" attributeFormDefault="unqualified"

> > > version="Ext">

> > >

> > > <!-- ===== Imports ===== -->

> > > <xsd:import

> > > namespace="urn:un:unece:uncefact:codelist:draft:54217:2001"

> > > schemaLocation="../../../LatestDraft-UBL-2.0/xsdrt/common/Code

> > > List_CurrencyC

> > > ode_ISO_7_04.xsd"/>

> > >

> > > <!-- ===== Type Definitions ===== -->

> > > <xsd:simpleType name="CurrencyCodeContentType">

> > > <xsd:union memberTypes="cur:CurrencyCodeContentType

> > > ExtCurrencyCodeContentType" />

> > > </xsd:simpleType>

> > > <xsd:simpleType name="ExtCurrencyCodeContentType">

> > > <xsd:restriction base="xsd:normalizedString">

> > > <xsd:enumeration value="FQD" />

> > > </xsd:restriction>

> > > </xsd:simpleType>

> > >

> > > </xsd:schema>

> > >

> > > where the imported schema contains the original

> enumerated list I'm

> > > extending

> > >

> > > <xsd:schema

> > > targetNamespace="urn:un:unece:uncefact:codelist:draft:54217:2001"

> > > xmlns:clm54217="urn:un:unece:uncefact:codelist:draft:54217:2001"

> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"

> > > elementFormDefault="qualified"

> > > attributeFormDefault="unqualified">

> > > <xsd:simpleType name="CurrencyCodeContentType">

> > > <xsd:restriction base="xsd:token">

> > > <xsd:enumeration value="AED"/>

> > > <xsd:enumeration value="AFN"/>

> > > ...

> > > <xsd:enumeration value="ZMK"/>

> > > <xsd:enumeration value="ZWD"/>

> > > </xsd:restriction>

> > > </xsd:simpleType>

> > > </xsd:schema>

> > >

> > > Is this a valid derivation from the original

> CurrencyCodeContentType ?

> > >

> > > I ask because when I try to create a substitutionGroup based

> > > in the derived

> > > type

> > > substituting an element based on the original type I find

> > > that the Microsoft

> > > Development Environment 2003 (for VS.NET 2003) throws an

> > > error claiming

> > > that the derivation isn't valid.

> > >

> > > I'm aware that there is variation still in how parsers support

> > > substitutionGroups

> > > and maybe that is the problem here, but equally I'd like any

> > > confirmation

> > > folk

> > > can give:

> > > that this is a tool error and/or

> > > that the derivation using union is sufficient for use in a

> > > substitution

> > > group

> > >

> > >

> > > My substitution looks like this:

> > >

> > > <xsd:element name="PricingCurrencyCode"

> > > substitutionGroup="cbc:PricingCurrencyCode"

> > > type="PricingCurrencyCodeType"

> > > />

> > >

> > > ...

> > > <xsd:complexType name="PricingCurrencyCodeType">

> > > <xsd:simpleContent>

> > > <xsd:extension base="sdt2-1:CurrencyCodeType"/>

> > > </xsd:simpleContent>

> > > </xsd:complexType>

> > >

> > > where the sdt21:CurrencyCodeType looks like

> > >

> > > <xsd:complexType name="CurrencyCodeType">

> > > <xsd:simpleContent>

> > > <xsd:extension base="cur:CurrencyCodeContentType">

> > > <xsd:attribute name="listID" type="xsd:normalizedString"

> fixed="4217"

> > > use="optional"/>

> > > ...

> > > <xsd:attribute name="listSchemeURI" type="xsd:anyURI"

> > > fixed="urn:oasis:names:prototype:ubl:schema:xsd:CurrencyCode-Ext"

> > > use="optional"/>

> > > </xsd:extension>

> > > </xsd:simpleContent>

> > > </xsd:complexType>

> > >

> > >

> > > The error message I get tells me:

> > >

> > > C:\Documents and

> > > Settings\admin\Desktop\SubstitutionGroups\Prototype-UBL-2.1\xs

> > > drt\common\UBL

> > > -CommonBasicComponents-2.1.xsd(21):

> > > 'urn:oasis:names:prototype:ubl:schema:xsd:CommonBasicComponent

> > > s-2.1:PricingC

> > > urrencyCode' cannot be a member of substitution group with

> > > head element

> > > 'urn:oasis:names:draft:ubl:schema:xsd:CommonBasicComponents-2.

> > > 0:PricingCurre

> > > ncyCode'. An error occurred at C:\Documents and

> > > Settings\admin\Desktop\SubstitutionGroups\Prototype-UBL-2.1\xs

> > > drt\common\UBL

> > > -CommonBasicComponents-2.1.xsd, (21, 3).

> > >

> > > C:\Documents and

> > > Settings\admin\Desktop\SubstitutionGroups\Prototype-UBL-2.1\xs

> > > drt\common\UBL

> > > -CommonBasicComponents-2.1.xsd(40): Invalid attribute

> > > restriction. An error

> > > occurred at file:///C:/Documents and

> > > Settings/admin/Desktop/SubstitutionGroups/Prototype-UBL-2.1/xs

> > > drt/common/UBL

> > > -SpecializedDatatypes-2.1.xsd, (40, 10).

> > >

> > >

> > > XML Spy 2005 gives no such error and valids an instance with

> > >

> > > ...

> > > <cbc:Note>sample</cbc:Note>

> > > <cbc2-1:PricingCurrencyCode>FQD</cbc2-1:PricingCurrencyCode>

> > > <cbc:LineExtensionTotalAmount

> > > currencyID="GBP">100.00</cbc:LineExtensionTotalAmount>

> > > ...

> > >

> > > as valid.

> > >

> > > I attach a set of schemas which I've been using (zip file

> > > with extension

> > > renamed to .zzz).

> > >

> > > Many thanks

> > >

> > > Stephen Green

> > >

> >

> >

> >

> > -----------------------------------------------------------------

> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an

> > initiative of OASIS <http://www.oasis-open.org>

> >

> > The list archives are at http://lists.xml.org/archives/xml-dev/

> >

> > To subscribe or unsubscribe from this list use the subscription

> > manager: <http://www.oasis-open.org/mlmanage/index.php>

> >

>

>

> -----------------------------------------------------------------

> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an

> initiative of OASIS <http://www.oasis-open.org>

>

> The list archives are at http://lists.xml.org/archives/xml-dev/

>

> To subscribe or unsubscribe from this list use the subscription

> manager: <http://www.oasis-open.org/mlmanage/index.php>

>

 

 

-----------------------------------------------------------------

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an

initiative of OASIS <http://www.oasis-open.org>

 

The list archives are at http://lists.xml.org/archives/xml-dev/

 

To subscribe or unsubscribe from this list use the subscription

manager: <http://www.oasis-open.org/mlmanage/index.php>