W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2006

Re: extension adds element removed by restriction (3.4.6/1.5)

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Thu, 26 Oct 2006 10:06:23 -0600
Message-Id: <446BA232-9E5E-43E1-BD22-4BE0784D8F4E@acm.org>
Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, <xmlschema-dev@w3.org>
To: "Moog, Thomas H" <thomas.h.moog@intel.com>

On 25 Oct 2006, at 23:12 , Moog, Thomas H wrote:

> Can someone give me an example of a sequence of
> restrictions and extensions which *cannot* be
> represented in the canonical form described in
> Section 3.6 (that is, one restriction followed by
> one extension (possibly empty), followed by one
> restriction (possibly empty) ?

I believe the example you give below is such an
example, as is the example given by Stan Kitsis
earlier in this thread.

> There is a rule which requires that all element
> in a model group with the same name have the
> same type (Section 3.8.1).
> In the case of complexType alpha with element
> "b" of type xs:gYear and complexType gamma with
> element "b" of type xs:integer, would this be
> a violation of that rule ?  I suspect not as
> alpha's "b" cannot be present when gamma's "b"
> is present.

For the canonical derivation to be possible, they
would both have to be present in the extension
step (beta):  one, because by hypothesis it's present
in the extension's base type (alpha) and extensions
do not delete things, the other because by hypothesis
it's present in the following restriction (gamma), and
can only get there by being present in beta.

That gives us a type which violates both the
Element Declarations Consistent and the Unique
Particle Attribution constraints.  (Or, as some people
would prefer to say, it gives us something which
cannot be a complex type, because it doesn't
satisfy the constraints.)

This seems to me a firm proof that the gamma type in
your example violates clause 1.5 of Schema Component
Constraint: Derivation Valid (Extension).  Some smart people
have said that they believed this clause was vacuous and
didn't actually forbid anything; I hope they are now persuaded
that it's not vacuous and it does need checking.

I hope this helps.

--C. M. Sperberg-McQueen

> <xs:complexType name="alpha">
>   <xs:sequence>
>      <xs:element name="a" />
>      <xs:element name="b" minOccurs="0" type="xs:gYear" />
>   </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:integer" />
>       </xs:sequence>
>     </xs:extension>
>   </xs:complexContent>
> </xs:complexType>
Received on Thursday, 26 October 2006 18:04:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:11 UTC