The schema is not valid, but I regret to say that the Saxon schema =
processor
also accepts it. It also accepts the instance

<x xsi:type="gamma" =
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <a/>
  <b>http://a.uri/</b>
</x>

as valid.

To illustrate the problems, change the type of "b" in alpha to =
xs:integer,
and run the query

import schema default element namespace "" at "test.xsd";
declare function local:f($x as element(*, alpha)) as xs:integer {
  $x/b + 3
};
local:f(*)

supplying the above document as the context item.

java com.saxonica.Query -sa -val -s test.xml test.xq

The result is a ClassCastException: the compiled code is expecting an
integer, but gets an anyURI value.

This will be fixed!


Michael Kay
http://www.saxonica.com/ 



> -----Original Message-----
> From: xmlschema-dev-request@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Stan Kitsis
> Sent: 24 October 2006 06:25
> To: C. M. Sperberg-McQueen; Moog, Thomas H
> Cc: xmlschema-dev@w...
> Subject: RE: extension adds element removed by restriction (3.4.6/1.5)
> 
> 
> > Now, if you changed your example, so that in alpha the 'b'
> > element was defined as having type xsd:gYear, for example, and then 
> > brought back in gamma with the type xsd:anyURI, then in principle 
> > conforming processors should reject it.
> 
> Can you explain why?  The following schema seems valid to me 
> and the .NET 2.0 processor agrees with me.
> 
> <xs:complexType name="alpha">
>   <xs:sequence>
>     <xs:element name="a" />
>     <xs:element name="b" type="xs:gYear" minOccurs="0" />
>   </xs:sequence>
> </xs:complexType>
> 
> <xs:complexType name="beta" >
>   <xs:complexContent>
>     <xs:restriction base="alpha" >
>       <xs:sequence>
>         <xs:element name="a" />
>       </xs:sequence>
>     </xs:restriction>
>   </xs:complexContent>
> </xs:complexType>
> 
> <xs:complexType name="gamma" >
>   <xs:complexContent>
>     <xs:extension base="beta" >
>       <xs:sequence>
>         <xs:element name="b" type="xs:anyURI"/>
>       </xs:sequence>
>     </xs:extension>
>   </xs:complexContent>
> </xs:complexType>
> 
> Stan Kitsis
> Microsoft Corporation
> 
> ________________________________________
> From: xmlschema-dev-request@w... 
> =FD[xmlschema-dev-request@w...]=FD On Behalf Of 
> xmlschema-dev-request@w... =FD[xmlschema-dev-request@w...]=FD
> Sent: Monday, October 23, 2006 6:46 PM
> To: Moog, Thomas H
> Cc: C. M. Sperberg-McQueen; xmlschema-dev@w...
> Subject: Re: extension adds  element removed by restriction 
> (3.4.6/1.5)
> 
> On 23 Oct 2006, at 07:59 , Moog, Thomas H wrote:
> 
> >
> >
> > In 3.4.6 (Constraints on Complex Type Definition Schema
> > Components) Section 1.5 there is this comment:
> >
> >     Note: This requirement ensures that nothing removed by a
> >     restriction is subsequently added back by an extension.
> >
> > The following schema is accepted by three schema validators.
> > I would expect gamma to be rejected because it adds back 
> element "b" 
> > which was removed when beta was created from alpha.
> >
> > I would appreciate it if someone would explain why this does not 
> > violate 3.4.6 section 1.5.
> 
> The note you quote is an attempt to paraphrase the effect of 
> the formal rule immediately preceding it; and unfortunately, 
> the invariant it formulates is not the invariant formulated 
> in the rule.
> 
> The rule (clause 1.5 of Schema Component Constraint:
> Derivation Valid (Extension) says any complex type must be so 
> constructed that it may be formulated as the result of a 
> three-step derivation: first the step defining a complex type 
> whose base type is xsd:anyType, then a single extension step, 
> then a restriction step.  As the note points out (after the 
> bit you quote), this is trivially satisfied if there is only 
> one extension step in the derivation (as is the case in your example).
> 
> The effective content model of gamma is the same as that of 
> alpha, so it's clearly possible to formulate it as a vacuous 
> extension of alpha, followed by a vacuous restriction.
> 
> A better formulation of the point made by the Note would be 
> that nothing, once taken away, gets put back with a 
> conflicting type assignment.  (If you put something back, its 
> new type must be the same as its old type, or a restriction of it.)
> 
> Indeed, the WG has just agreed to such a change in 
> formulation in order to resolve issue 2235 (which talks about 
> attributes, but concerns fundamentally your point).
> 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=2235
> 
> Now, if you changed your example, so that in alpha the 'b'
> element was defined as having type xsd:gYear, for example, 
> and then brought back in gamma with the type xsd:anyURI, then 
> in principle conforming processors should reject it.
> I have not tried this on any processors, though. I'd be 
> interested in seeing whether the three you are testing accept 
> or reject such a modified example.
> 
> I hope this helps,
> 
> --C. M. Sperberg-McQueen
>    World Wide Web Consortium
> 


From paul.spencer@b... Tue Oct 24 11:20:16 2006
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1GcKKO-00085j-8X
	for xmlschema-dev@listhub.