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@w3.org ý[xmlschema-dev-request@w3.org]ý On Behalf Of xmlschema-dev-request@w3.org ý[xmlschema-dev-request@w3.org]ý
Sent: Monday, October 23, 2006 6:46 PM
To: Moog, Thomas H
Cc: C. M. Sperberg-McQueen; xmlschema-dev@w3.org
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

Received on Tuesday, 24 October 2006 05:25:05 UTC