RE: [xml-dev] Is there a way to reuse and extend an enumeration in XML schema

["Marty Burns" <burnsmarty@comcast.net>]

Henry et al,

I am trying to apply your method. I have started with the current
UBL schemas. I am having some difficulty making this work. 

What I tried was:

1) UBL code list schema contains type xsd:normalizedString code list but no
values.
2) Created separate schema that contains a redefine of code list with
standard set of enumerated values.
3) Created schema that includes all subsidiary schemas in addition to the
one with the desired enumerated values. Some of these included schemas
themselves have included the code list schema.

Problem: Parser chokes on the redefine because the base code list was
imported or included in the other UBL schema documents -- that is where code
lists are used in document designs.

Do I have a cockpit problem here or do you see a workaround? 

This is by far the potentially most elegant solution to code list
extensibility because the customizer would need to import a list of pointers
to his selected code list enumerations to be used in validation of instance
documents. 

I have attached some working files in case there is a simple error.

Marty

-----Original Message-----
From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] 
Sent: Thursday, March 10, 2005 6:35 AM
To: William J. Kammerer
Cc: XML Developers List
Subject: Re: [xml-dev] Is there a way to reuse and extend an enumeration in
XML schema

I've worked a trivial example to fill out and illustrate the redefine
approach I sent earlier.

Here's the base schema, published by the namespace owner:

curEnumBase.xsd:

<xs:schema targetNamespace="http://www.example.com/fakeUBL";
 xmlns="http://www.example.com/fakeUBL";
 xmlns:xs="http://www.w3.org/2001/XMLSchema";>
 <!-- Example base schema for extensible enumerations -->
 <xs:element name="currency" type="currencyCodeType"/>
 
 <xs:simpleType name="currencyCodeType">
  <xs:restriction base="xs:NMTOKEN"/>
 </xs:simpleType>
</xs:schema>

Here's the vanilla driver schema, likewise published by the namespace
owner:

curEnumDriver.xsd:

<xs:schema targetNamespace="http://www.example.com/fakeUBL";
 xmlns="http://www.example.com/fakeUBL";
 xmlns:xs="http://www.w3.org/2001/XMLSchema";>
 <!-- Example driver schema for extensible enumerations -->
 
 <xs:redefine schemaLocation="curEnumBase.xsd">
  <xs:simpleType name="currencyCodeType">
   <xs:restriction base="currencyCodeType">
    <xs:enumeration value="UKL"/>
    <xs:enumeration value="USD"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:redefine>
</xs:schema>

And here's a valid instance:

<currency xmlns="http://www.example.com/fakeUBL";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://www.example.com/fakeUBL
 curEnumDriver.xsd">
 UKL
</currency>

And an invalid one:

<currency xmlns="http://www.example.com/fakeUBL";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://www.example.com/fakeUBL
 curEnumDriver.xsd">
 CAD
</currency>

To make it valid, we make our own extended driver:

curEnumExt.xsd:

<xs:schema targetNamespace="http://www.example.com/fakeUBL";
 xmlns="http://www.example.com/fakeUBL";
 xmlns:xs="http://www.w3.org/2001/XMLSchema";>
 <!-- Example extended schema for extensible enumerations -->
 
 <xs:redefine schemaLocation="curEnumBase.xsd">
  <xs:simpleType name="currencyCodeType">
   <xs:restriction base="currencyCodeType">
    <xs:enumeration value="UKL"/>
    <xs:enumeration value="USD"/>
    <xs:enumeration value="CAD"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:redefine>
</xs:schema>

and if we change the xsi:schemaLocation of our example to point to
this driver, it's valid.

As it happens, Dan Vint and colleagues had arrived at this solution
long before I proposed it. He described it in much more detail in a
recent post to xmlschema-dev [1], including the following, which says
it all, IMO:

  1) Produce a base schema that references a type for each list with no
     enumerations [e.g. curEnumBase].
  2) Produce a second schema that redefines those list types to the
     enumerated values [e.g. curEnumDriver].

  Anyone needing to modify those lists modifies the second redefining
  schema [e.g. curEnumExt]. Now when I release the next version, all
  that has to happen is the modifier reviews the new redefining schema
  for new lists. These changes have to be copied into the file they
  originally modified. They also have to find any changes to the
  existing lists as well.

  They then use the newly produced base schema and point their modified
  redefine schema to point at the this file instead of the original base
  schema.

  This has the advantage of creating one single file with all the
  modifications. It still is not a perfect solution, but it is the best
  compromise that we could come up with.

  We also made the type of the lists to be QNAME and we require that
  anyone adding a value to a list use an appropriate namespace prefix to
  identify their additions.

  ['e.g.'s added]

Some further observations:

 1) The publisher could make this approach easier if they used an
    external general entity to include the enumerations in the
    redefining schema document:

    curEnumDriver.xsd:

    <!DOCTYPE xs:schema [
    <!ENTITY currencyEnumeration SYSTEM
 
"http://www.example.com/fakeUBL/currencies.xnt";>
    ]>
    <xs:schema targetNamespace="http://www.example.com/fakeUBL";
     xmlns="http://www.example.com/fakeUBL";
     xmlns:xs="http://www.w3.org/2001/XMLSchema";>
     <!-- Example driver schema for extensible enumerations -->

     <xs:redefine schemaLocation="curEnumBase.xsd">
      <xs:simpleType name="currencyCodeType">
       <xs:restriction base="currencyCodeType">
        &currencyEnumeration;
       </xs:restriction>
      </xs:simpleType>
     </xs:redefine>
    </xs:schema>

    Then the extension can track the official list and changes thereto
    more easily:

    curEnumExt.xsd:

    <!DOCTYPE xs:schema [
    <!ENTITY currencyEnumeration SYSTEM
 
"http://www.example.com/fakeUBL/currencies.xnt";>
    ]>
    <xs:schema targetNamespace="http://www.example.com/fakeUBL";
     xmlns="http://www.example.com/fakeUBL";
     xmlns:xs="http://www.w3.org/2001/XMLSchema";>
     <!-- Example driver schema for extensible enumerations -->

     <xs:redefine schemaLocation="curEnumBase.xsd">
      <xs:simpleType name="currencyCodeType">
       <xs:restriction base="currencyCodeType">
        &currencyEnumeration;
        <xs:enumeration value="CAD"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:redefine>
    </xs:schema>

 2) This approach works directly for types used for attributes _or_
    elements, whereas any approach using substitution groups (which
    are very useful for many things, but not this problem, in my
    opinion) only works directly for elements.

Hope this helps -- if you think it does, please pass it on to the UBL
list. . .

ht

[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2005Mar/0008.html
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged
spam]

-----------------------------------------------------------------
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>

WorkingRedefineUseCase20050502.zip