RE: Derivation by restriction from <any>

So after all this, do I understand that: 
(a) Dare agrees with MSXML that my original schema[1] is invalid; 
while 
(b) Jeni originally agreed with Henry that it was OK, but now thinks it is
unclear
?  

I'm having some difficult untangling the thread 
and relating it to my original question!  

Meanwhile, if Dare and MSXML are correct, 
then perhaps I should rephrase the question:  

How can I define 
a base type that will accept *any* elements in its content model, 
and then define 
a type derived from this by restriction that confines the 
content to a specific vocabulary?  
(to be used for elements in a substitution group) 

Am I reduced to using the very weak inheritance method 
of first emptying the content and then extending it?

[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2002Mar/0015.html

_____
Simon.Cox@csiro.au  CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151
PO Box 1130, Bentley WA 6102  AUSTRALIA
T: +61 (8) 6436 8639  F: +61 (8) 6436 8555  C: +61 (4) 0330 2672
http://www.csiro.au/page.asp?type=resume&id=CoxSimon

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Saturday, 9 March 2002 7:51 PM
> To: Dare Obasanjo
> Cc: xmlschema-dev@w3.org
> Subject: Re: Derivation by restriction from <any>
> 
> 
> Hi Dare,
> 
> >> By the rules of the Schema Component Constraint: Particle Valid
> >> (Restriction) 
> >> (http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict), 
> >> the sequence in the base model group is "pointless" so the 
> >> base model group is equivalent to:
> >
> [snip]
> > The rules for pointlessness for an xs:sequence are
> >
> >         <sequence> 
> >         One of the following must be true:
> >         2.2.1 {particles} is empty. [Dare - Nope, not in this case] 
> >
> >         2.2.2 All of the following must be true:
> >         2.2.2.1 The particle within which this <sequence> 
> appears has
> > {max occurs} and {min   occurs} of 1. [Dare - the sequence does not
> > appear in a particle. Now it is possible that somewhere in the spec
> > defines some implicit particle similar to how there is an implicit
> > xs:complexContent child of a xs:complexType when it has particles as
> > children. If this is the case I'd appreciate it if you 
> could point this
> > out]
> 
> Yes :) I admit that I performed a little 'interpretation' of the spec
> here, and went with what I felt was the spirit rather than the letter.
> 
> It's clear that 2.2.2.1 does not apply to a <sequence> that is the
> top-level particle in a content model, since it does not appear within
> a particle itself. The question is whether the fact that it does not
> appear within a particle means that the condition is met or not met,
> in other words, does 2.2.2.1 mean:
> 
>   "If the <sequence> appears within a particle, then the particle
>    within which this <sequence> appears has {max occurs} and {min
>    occurs} of 1."
> 
> or does it mean:
> 
>   "The <sequence> appears within a particle and the particle
>    within which this <sequence> appears has {max occurs} and {min
>    occurs} of 1."
> 
> I think that both interpretations are valid interpretations based on
> the letter of the Rec. I think that the former interpretation, which
> is the one that I made, makes more sense, by extension, since if you
> had:
> 
>   <choice>
>     <sequence>
>       <any maxOccurs="unbounded" />
>     </sequence>
>     <element ref="baz" />
>   </choice>
> 
> being restricted to:
> 
>   <choice>
>     <sequence>
>       <element ref="foo" />
>       <element ref="bar" />
>     </sequence>
>     <element ref="baz" />
>   </choice>
> 
> Then that would be OK - the sequence in the base is *definitely*
> pointless, and the map from the base any to the restricted sequence
> is fine (as I demonstrated in the last message).
> 
> But then again, if you have the base particle:
> 
>   <sequence maxOccurs="unbounded">
>     <any />
>   </sequence>
> 
> and the restriction:
> 
>   <sequence>
>     <element ref="foo" />
>     <element ref="bar" />
>   </sequence>
> 
> To my eyes, that looks like a valid restriction, but according to the
> Rec I don't think it is. The sequence/sequence derivation rule states
> that the there must be an order-preserving functional mapping between
> the particles making up the two sequences, which there clearly isn't
> in this case - there's nothing for the second element to map on to.
> 
> And if it doesn't work for the above base model group, then it
> shouldn't work for the model group:
> 
>   <sequence>
>     <any maxOccurs="unbounded" />
>   </sequence>
> 
> which I think is functionally equivalent.
> 
> As usual with these things, the not-quite-errata document registers
> that there's already been a comment about the pointlessness rules:
> 
>   http://www.w3.org/2001/05/xmlschema-rec-comments#pfipointless
> 
> Apparently it's been resolved:
> 
>   "The WG has decided that although the rules have some awkward
>    results, they are not in error. It will be put on the list of
>    issues to consider for a future revision of XML Schema."
> 
> So there you go. I guess that means that one-to-many mappings are
> possible in some cases but not in others (with a little ambiguity
> about which examples fall into which class).
> 
> Cheers,
> 
> Jeni
> 
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Monday, 11 March 2002 20:58:09 UTC