[
Lists Home |
Date Index |
Thread Index
]
Henry,
Thanks for your interesting post. I am the editor of the UBL code list
specification and I think your solution may help us trade off some
difficulties we have with our present solution.
We have considered substitution groups because:
1) You could define a substitution once and have it reflect everywhere
without modifying the base schema or, also importantly, a third party code
list schema that UBL has incorporated by reference.
2) Your modified schema's namespace would prefix all uses so that you
explicitly know which fields are modified in the instance file.
Problems with the substitution group method are:
1) Many UBL elements are derived from the code list types. Therefore
additional definitions would be needed -- eg <xsd:element name='myCode'
type='stdCodeListType'/> instead of using the global code by reference.
2) Problem number 1 is compounded by the desire to use code lists as
attributes as well as elements. Thus you would have to have all elements
containing code attributes be global and substitute them.
3) Because substitution groups are unconstrained, discipline would need to
be used to ensure that it was only used for code list extension /
restriction. This gives the UBL naming and design rules team great concern.
I guess the only minor downsides I see to your redefine method is:
1) you would have to look to the schemaLocation attribute in the instance
file to recognize that the redefinitions occurred.
2) you would not be able to pick and choose which instances of the code list
is overridden -- e.g. one instance uses <cl:code>foo</> and another uses
<customCl:code>foo</>.
3) This is more of a question -- is it possible to redefine several types
from different namespaces in a single schema file so there would be a single
incorporation of all changes referenced in the schemaLocation attribute of
the instance file.
Thanks again for highlighting a promising solution that might be able to
meet all the UBL requirements.
Marty Burns,
Hypertek for NIST
1(301)315-9101
burnsmarty@aol.com
-----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">
¤cyEnumeration;
</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">
¤cyEnumeration;
<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>
|