RE: simpleType redefinition - must it be a restriction?

We considered this, and it is a possible fallback for us. 

By concentrating the changes to a single file, it strikes a pragmatic
balance between having a locked-down (inflexible) schema and having a
wide-open (user-damageable) schema.

The downside of such an approach is that is requires either 1) the schema
owner must rapidly field requests and post extensions, or 2) the schema user
must copy the schema, in its entirety, insert his own extensions locally,
and re-post the extended schema so that interchange partners can benefit
from the extension. 

The former breaks down when the schema owner is not responsive enough. The
latter breaks down as more and more parties replicate the schema and make
(potentially non-coordinated) changes to it. Option 2 also breaks down as
layers are built up (schema C is built on schema B which is built on schema
A, all of which do some kind of extension,...).

I'm not sure what it means to  build this approach into the Schema Rec. - it
can be done today, using simpleType definitions and include/import. What
would be nifty would be to allow a redefine that would support the extension
of the enumeration set, something that I gather would meet significant
resistance, since it would remove a key assumption about the
completeness/finality of a simpleType definition.

Mark

----------------------------------------------------------------------------
----
 
Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
mfeblowitz@frictionless.com
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
www.frictionless.com  
 

 -----Original Message-----
From: 	Ashok Malhotra [mailto:ashokma@microsoft.com] 
Sent:	Tuesday, January 08, 2002 9:59 AM
To:	Mark Feblowitz; Jeni Tennison
Cc:	Xmlschema-Dev (E-mail); Henry Thompson (E-mail)
Subject:	RE: simpleType redefinition - must it be a restriction?

A better solution is to allow the enumerations to be specified in a
separate file which can be updated independent of the Schema.  This is a
significant change that we can consider for Schema 1.1 or 2.0

All the best, Ashok 
===========================================================
Ashok Malhotra              <mailto: ashokma@microsoft.com> 
Microsoft Corporation




-----Original Message-----
From: Mark Feblowitz [mailto:mfeblowitz@frictionless.com] 
Sent: Monday, January 07, 2002 3:00 PM
To: 'Jeni Tennison'
Cc: Xmlschema-Dev (E-mail); Henry Thompson (E-mail)
Subject: RE: simpleType redefinition - must it be a restriction?

> 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 4.3.5.5 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:restriction>
	</xs:simpleType>
	<xs:simpleType name="CurrencyCodeExtended">
		<xs:union memberTypes="CurrencyCode
CurrencyCodeExtensions"/>
	</xs:simpleType>
	<xs:simpleType name="CurrencyCodeExtensions">
		<xs:restriction base="xs:string">
			<xs:enumeration value="AUD"/>
		</xs:restriction>
	</xs:simpleType>

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"
attributeFormDefault="unqualified">
	<xs:simpleType name="CurrencyCode">
		<xs:restriction base="xs:string">
			<xs:enumeration value="USD"/>
			<xs:enumeration value="EUR"/>
		</xs:restriction>
	</xs:simpleType>
</xs:schema>

<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
CurrencyCodeExtensions"/>
	</xs:simpleType>
	<xs:simpleType name="CurrencyCodeExtensions">
		<xs:restriction base="xs:string">
			<xs:enumeration value="AUD"/>
		</xs:restriction>
	</xs:simpleType>
</xs:schema>

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?

Thanks,

Mark


------------------------------------------------------------------------
----
----
 
Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
mfeblowitz@frictionless.com
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
www.frictionless.com  
 

 -----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
(USD, AUD).

According to the XML Schema Datatypes Rec, Section 4.3.5.5 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.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Tuesday, 8 January 2002 10:32:26 UTC