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

Re: Restricting substitution groups?

From: Eric van der Vlist <vdv@dyomedea.com>
Date: Wed, 06 Feb 2002 09:52:19 +0100
Message-ID: <3C60EEC3.4020405@dyomedea.com>
To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>, xmlschema-dev@w3.org
Hi Henry,

As mentioned by Jeni and Noah in their answers, it would be nice to get 
a definitive answer and you are probably the only one who can give it :) !

Untill we get such an answer, my position is that since the result of 
this restriction relies on something (the order of elements in a 
substitution group) which is undefined, restriction of substitution 
groups are themselves undefined and should be avoided as source of 
potential interroperability issues.

Thanks

Eric

PS:IMO, the clean way to to fix the issue would be to suppress the 
constraint about the order of the particles during restrictions of 
xs:choice.


Eric van der Vlist wrote:

> Sorry to insist ;=) ... is the question that stupid or a FAQ?
> 
> Eric
> 
> Eric van der Vlist wrote:
> 
> 
>>Given that a substitution group is kind of equivalent to xs:choice:
>>
>>http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict
>>
>>
>>2.1 Any top-level element declaration particle (in R or B) which is the 
>>{substitution group affiliation} of one or more other element 
>>declarations is treated as if it were a choice group whose {min occurs} 
>>and {max occurs} are those of the particle, and whose {particles} 
>>consists of one particle with {min occurs} and {max occurs} of 1 for the 
>>top-level element declaration and for each of the declarations in its 
>>·substitution group·.
>>
>>Does that mean that we can restrict substitution groups?
>>
>>If for instance I have:
>>
>><xs:element name="head"/>
>><xs:element name="a" substitutionGroup="head"/>
>><xs:element name="b" substitutionGroup="head"/>
>><xs:element name="c" substitutionGroup="head"/>
>>
>>and:
>>
>><xs:complexType name="base">
>>  <xs:sequence>
>>    <xs:element ref="head"/>
>>  </xs:sequence>
>></xs:complexType>
>>
>>is
>>
>><xs:complexType name="derived">
>>  <xs:complexContent>
>>   <xs:restriction base="base">
>>    <xs:sequence>
>>      <xs:choice>
>>        <xs:element ref="a"/>
>>        <xs:element ref="b"/>
>>      </xs:choice>
>>    </xs:sequence>
>>   </xs:restriction>
>>  </xs:complexContent>
>></xs:complexType>
>>
>>a valid restriction?
>>
>>I guess not since it doesn't seem to match the condition for restricting 
>>choices:
>>
>>Schema Component Constraint: Particle Derivation OK (Choice:Choice -- 
>>RecurseLax)
>>For a choice group particle to be a ·valid restriction· of another 
>>choice group particle all of the following must be true:
>>1 R's occurrence range is a valid restriction of B's occurrence range as 
>>defined by Occurrence Range OK (§3.9.6);
>>2 There is a complete ·order-preserving· functional mapping from the 
>>particles in the {particles} of R to the particles in the {particles} of 
>>B such that each particle in the {particles} of R is a ·valid 
>>restriction· of the particle in the {particles} of B it maps to as 
>>defined by Particle Valid (Restriction) (§3.9.6).
>>NOTE: Although the ·validation· semantics of a choice group does not 
>>depend on the order of its particles, derived choice groups are required 
>>to match the order of their base in order to simplify checking that the 
>>derivation is OK.
>>
>>The question should then probably be which is the order of the elements 
>>of a substitution group when they are mapped to a xs:choice during 
>>validation (and how can this be used to restrict a substitution group) ?
>>
>>Thanks
>>
>>Eric
>>
>>
> 
> 
> 



-- 
Rendez-vous a Paris pour mes formations XML/XSLT.
                                           http://dyomedea.com/formation/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------
Received on Wednesday, 6 February 2002 03:52:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:26 GMT