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

Re: can an attribute prohibited by restriction be added back through a subsequent extension?

From: Eddie Robertsson <erobertsson@allette.com.au>
Date: Wed, 31 Jul 2002 10:39:16 +1000
Message-ID: <3D4731B4.7050006@allette.com.au>
To: Eddie Robertsson <erobertsson@allette.com.au>
CC: Priya Lakshminarayanan <priyal@microsoft.com>, xmlschema-dev@w3.org, Yan Leshinsky <yanl@microsoft.com>

Hi again,

It seems some of my last email got lost on the way so I'll try again...


This has been in my inbox now for quite some time and I was actually 
waiting for some of the experts on the list to make a comment on this. 
Maybe you have received a private answer but since I'm interested in 
this as well I thought I'd give it ago.

Priya Lakshminarayanan wrote:

> Is the following derivation sequence valid??
>  <xs:complexType name="CT">
>                        <xs:attribute name="x" type="xs:int"/>
>                         <xs:attribute name="y" type="xs:int"/>
> </xs:complexType>
>  <xs:complexType name="CT2">
>                   <xs:complexContent>
>                         <xs:restriction base="CT">
>                           <xs:attribute name="x" type="xs:int" 
> use="prohibited"/>
>                         </xs:restriction>
>                   </xs:complexContent>
>  </xs:complexType>
>   <xs:complexType name="CT3">
>                   <xs:complexContent>
>                         <xs:extension base="CT2">
>                           <xs:attribute name="x" type="xs:int"/>
>                         </xs:extension>
>                   </xs:complexContent>
>   </xs:complexType>
> I specifically need clarification on the following part of the spec:
> *Schema Component Constraint: Derivation Valid (Extension)*
>     1.5 It must in principle be possible to derive the complex type 
> definition in two steps, the first an extension and the second a 
> restriction (possibly vacuous), from that type definition among its 
> ancestors whose {base type definition} 
> <http://www.w3.org/TR/xmlschema-1/#ct-base_type_definition#ct-base_type_definition> 
> is the **ur-type definition** 
> <http://www.w3.org/TR/xmlschema-1/#ur-type-itself#ur-type-itself>.
> *NOTE: **This requirement ensures that nothing removed by a 
> restriction is subsequently added back by an extension*. It is trivial 
> to check if the extension in question is the only extension in its 
> derivation, or if there are no restrictions bar the first from the 
> **ur-type definition** 
> <http://www.w3.org/TR/xmlschema-1/#ur-type-itself#ur-type-itself>.

Based on the above sentence I would say that the above example is not 
legal since the type CT3 tries to add back an attribute that was 
prohibited in a previous derivation step.

>  Constructing the intermediate type definition to check this 
> constraint is straightforward: simply re-order the derivation to put 
> all the extension steps first, then collapse them into a single 
> extension. If the resulting definition can be the basis for a valid 
> restriction to the desired definition, the constraint is satisfied.
I've also tried to apply this rule to the above example and if I'm doing 
that correctly then the example is invalid. To test the above you should 
reorder the derivation steps so that all extensions come first. The base 
type is:

<xs:complexType name="CT">
    <xs:attribute name="x" type="xs:int"/>
    <xs:attribute name="y" type="xs:int"/>

Now we reorder the derivation steps so that the next step will be the 
extension which would be something like this:

<xs:complexType name="test">
        <xs:extension base="CT1">
            <xs:attribute name="x" type="xs:int"/>

Now, I think the above is illegal since you try to add the attribute x 
to a type that already have an attribute x but I couldn't find where 
this was specified in the rec. If I'm correct and the above is indeed 
illegal then the test would fail and hence the above example would be 
invalid. I decided to test this with a couple of W3C XML Schema 
validators and got the following results:

Invalid - XML Spy 4.4

Valid - XSV, SQC, Xerces (2.0.1), MSXML4

I was very surprised at this result so I guess I missed something in my 
above conclusion.

Can anyone comment on this?

Received on Tuesday, 30 July 2002 20:24:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC