W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2002

RE: simpleType redefinition - must it be a restriction?

From: Mark Feblowitz <mfeblowitz@frictionless.com>
Date: Mon, 7 Jan 2002 18:00:17 -0500
Message-ID: <4DBDB4044ABED31183C000508BA0E97F024D5693@fcpostal.frictionless.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>
Cc: "Xmlschema-Dev (E-mail)" <xmlschema-dev@w3.org>, "Henry Thompson (E-mail)" <ht@cogsci.ed.ac.uk>
> Redefinitions of a simple type must be restrictions of that simple
> type (since <simpleType> elements within a <redefine> element must
> have a <restriction> child). Restrictions within a redefine follow the
> same rules as restrictions elsewhere.

That having been stated (and also in ht's message on 11/6/2001,
http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0047.html), is
there any valid means of achieving the effect of adding enumerations to a
simpleType (i.e., extending a simpleType), without altering the original
definition? It looks like the simple answer is no, given XML Schema
Datatypes Rec, Section Constraints on enumeration Schema Components.

Still, the situation often arises where additional enumerated values are
needed "between schema releases." The example in my initial query is one
such case: the  set of currency codes is relatively stable, but new
currencies do sometimes emerge (we have many other similar examples, not
just currencies). We would like the schema to validate that a currency code
is one of the set of valid enumerations, but we also need a way to support
transactions that use the new currency code(s). Simply "changing the schema"
is not an option in cases where many parties are relying on a stable schema
and a predictable release schedule.

Ideally, we would like some way to extend the schema to add one or more
enumerations to the original simpleType (e.g., by using a redefine). That
was the source of my initial example, and looks not to be conformant.
Alternately we might want to create a same-named type in another namespace,
adding the new enumerated values to the new type. That looks like it won't
work, either, and for the same reason: the new type must be a restriction of
the base type, which is already more constrained than we'd like (i.e., it
disallows the new currencies).

It would be possible to create a new simpleType which extends the original
set by the use of a union

	<xs:simpleType name="CurrencyCode">
		<xs:restriction base="xs:string">
			<xs:enumeration value="USD"/>
			<xs:enumeration value="EUR"/>
	<xs:simpleType name="CurrencyCodeExtended">
		<xs:union memberTypes="CurrencyCode
	<xs:simpleType name="CurrencyCodeExtensions">
		<xs:restriction base="xs:string">
			<xs:enumeration value="AUD"/>

Trouble is, this new type can only be used in new definitions (i.e., that
refer to the newly created type CurrencyCodeExtended) and not in any of the
other contexts where CurrencyCode is already in use. This means that the new
currency codes would be valid only in a fraction of the places where
currency codes are used. And, unless I'm mistaken, the types/elements that
refer to the original type CurrencyCode can't be redefined to use the new
CurrencyCodeExtended type, because the latter isn't a restriction of base
type CurrencyCode.

Another approach, which uses two namespaces, creates a new type
ns2:CurrencyCode that is defined as the original CurrencyCode type in ns1
unioned with an expansion set, ns2:CurrencyCodeExtensions:

<xs:schema targetNamespace="ns1" xmlns="ns1"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
	<xs:simpleType name="CurrencyCode">
		<xs:restriction base="xs:string">
			<xs:enumeration value="USD"/>
			<xs:enumeration value="EUR"/>

<xs:schema targetNamespace="ns2" xmlns:ns1="ns1"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="ns2"
elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="ns1" schemaLocation="unionSimple1.xsd"/>
	<xs:simpleType name="CurrencyCode">
		<xs:union memberTypes="ns1:CurrencyCode
	<xs:simpleType name="CurrencyCodeExtensions">
		<xs:restriction base="xs:string">
			<xs:enumeration value="AUD"/>

While legal, this suffers from the same problem that the redefine approach
suffers from: the new currencies only appear in new definitions that use
ns2:CurrencyCode. To resolve this, types that reference ns1:CurrencyCode
would have to be copied from ns1 into ns2 and altered to reference
ns2:CurrencyCode instead of ns1:CurrencyCode. That, like so many cases of
derivation by restriction, causes a replication maintenance nightmare.

I have also experimented with some tricks with union types, creating a base
type that is the product of unioning a core type plus an unconstrained
xs:string extension (as suggested in
http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0047.html). Any
such approach would require the unioning of a less restrictive set in order
to subsequently allow the new enumerations to be viewed as legitimate
restrictions. The initial set of enumerations would then only act as
documentation and not be usable for validation purposes (a set of strings
unioned with the set of all strings is the set of all strings), until one or
more new enumerations was added to constrain that other, wide-open set. That
trick also breaks down in other cases, e.g, when more that one namespace
needs to extend the enumeration.

So, my question again is this: is there any way to achieve an extended set
of enumerated values, or must I basically throw away enumeration for all but
the most stable types?



Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
400 Technology Square, 9th Floor 
Cambridge, MA 02139 

 -----Original Message-----
From: 	Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent:	Saturday, January 05, 2002 8:15 AM
To:	Mark Feblowitz
Cc:	Xmlschema-Dev (E-mail); Henry Thompson (E-mail);
'support@xmlspy.com'; 'al@altova.com'
Subject:	Re: simpleType redefinition - must it be a restriction?

Hi Mark,

> Must a redefinition of a simpleType result in a more constrained
> simpleType? Or can it be less constrained?

Redefinitions of a simple type must be restrictions of that simple
type (since <simpleType> elements within a <redefine> element must
have a <restriction> child). Restrictions within a redefine follow the
same rules as restrictions elsewhere.

> XMLSpy says that any of AUD, EUR, USD or USD (!) are allowed in the
> instance document that references the redefinition xsd. It appears
> to have created a union of the original and the redefined
> enumeration sets.
> XSV says that only USD and AUD are allowed, treating the redefined
> enumeration set as overriding the original.
> I expected the redefinition to be flagged as an error, with the new
> definition not being a proper subset of the original.
> What is the correct interpretation?

I think your interpretation is the correct interpretation. When you
restrict a simple type, the facets have to be valid restrictions of
the facets of the base type. In your example the base type had a value
space of (USD, EUR); the derived type had an enumeration facet of

According to the XML Schema Datatypes Rec, Section Constraints
on enumeration Schema Components:

  Schema Component Constraint: enumeration valid restriction

  It is an ˇerrorˇ if any member of {value} is not in the ˇvalue
  spaceˇ of {base type definition}.

The restriction is therefore an error because the value 'AUD' is not
in the value space of the base type.



Jeni Tennison
Received on Monday, 7 January 2002 18:00:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:54 UTC