Re: Inconsistency between equivClass and key ?

cedric thienot <cedric.thienot@lip6.fr> writes:

> Dear all,
> 
> We would like to make two comments to XML schema.
> 
> 1. use of XPath and the equivalence Class and inheritance mechanism:
> 
> Imagine the following schema:
> 
> <element name="e1" type="t1" equivClass="e2"/>
> <element name="e2" type="t1"/>
> 
> <complexType name="t1">
> 	<attribute="a1" type="integer"/>
> </complexType>
> 
> <element name="e3">
> 	<complexType>
> 		<element ref="e1"/>
> 	</complexType>
> 	<key name="k1">
> 		<selector>e1</selector>
> 		<field>@a1</field>
> 	</key>
> </element>
> 
> Does this schema validate the following description:
> 	<e3>
> 		<e1 a1="2"/>
> 	</e3>
> 	<e3>
> 		<e2 a1="2"/>
> 	</e3>
> 
> In other word, how XPath (in the selector tag) handles the equivalence
> class mechanism ?

Not at all (yet).  The key declared for e3 is not satisfied by the
above instance -- there's no e1.  Until XPath becomes schema-aware,
there is a weakness here, you're right.

> 2) reusability and evolution of type when derived by restriction.
> 
> If you define a type:
> 
> 	<complexType name="t1">
> 		<element name="e1" type="integer" minOccur="0" maxOccur="4"/>
> 	</complexType>
> 
> and someone else reuses this type by extending by restriction
> 
> 	<complexType name="t12" derivedBy="restriction">
> 		<element name="e1" type="integer minOccur="0" maxOccur="3"/>
> 	</complexType>

Presumably you meant "base='t1'"

> Therefore, You can not change the type t1 without affecting the type
> t2: You are not allowed to make your type t1 evolve by adding
> something.  otherwise the type t12 would not be correct anymore (if
> you derived by restriction, you need to rewrite the entire content
> model of the type).  In a development environment, the need of
> improving schemas will certainly occurs. It should affect as few as
> possible other dependent schemas.

Any use-by-reference mechanism has this property in the face of
versioning.  If you own both schemas, you'll do your best to change t1 
in ways that don't break t2.  If you make changes that break
derivation, and you know you have clients, you should issue a distinct 
new version -- same story in any other domain, not just schemas.

> Two solutions are proposed in XML schema:
> 
> 1) either you block the inheritance mechanism. none type can derived
> of t1 (the definition of t2 is not allowed). Therefore, your schema
> is not extensible.
> 
> 2) You redefine every subtype of t1. It doesn't make sense.
> 
> One solution (not defined in XML schema) would be to identify
> restricted elements by using an XPath expression instead of a full
> redefinition

We considered this and decided it would be much too verbose.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Wednesday, 7 June 2000 11:54:20 UTC