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

Re: Newbie question regarding restriction

From: Eddie Robertsson <erobertsson@allette.com.au>
Date: Tue, 05 Nov 2002 09:59:25 +1100
Message-ID: <3DC6FBCD.7040808@allette.com.au>
To: Vineet Chaoji <chaoji@roguewave.com>
CC: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>

Hi Vineet,

>I have the following schema:
>
><xs:complexType name="ImageDict">
>  <xs:sequence>
>    <xs:element name="ColorSpace">
>      <xs:complexType>
>        <xs:complexContent>
>          <xs:restriction base="Object_t">
>            <xs:choice>
>              <xs:element name="Name" type="Name_t" />
>              <xs:element name="Array" type="Array_t" />
>            </xs:choice>
>          </xs:restriction>
>        </xs:complexContent>
>      </xs:complexType>
>    </xs:element>
>        .......
>       ........
>  </xs:sequence>
></xs:complexType>
> 
><xs:complexType name="Object_t">
>  <xs:annotation>
>    <xs:documentation></xs:documentation>
>  </xs:annotation>
>  <xs:attribute name="ID" type="xs:ID" use="optional" />
>  <xs:attribute name="IDREF" type="xs:IDREF" use="optional" />
></xs:complexType>
>
>The ColorSpace element inside the ImageDict complexType restricts Object_t.
>But the Name and Array elements (inside the choice) that it is trying to 
>restrict are not present in the base complexType.
>As per my understanding, for restriction the particle that is being
>restricted 
>has to be present in the complexType that is being restricted.
>
>Am I correct (and that means that the schema is incorrect)?
>
Yes, you are correct. When creating a derivation by restriction the 
first rule is very simple: derivation by restriction can *never* (Gee, 
I'm using never again...I wonder if Henry will prove me wrong again...) 
add anything that is not already allowed by the base type. A derivation 
by restriction will only restrict what is already there.

In your case above it seems you're just trying to add a choice group to 
the content so you can just change <restriction> to <extension> in the 
above example.

>I tried looking at the spec but couldnt find anything concrete that ratifies
>my understanding.
>Could you point out the section in the spec that confirms/negates my
>understanding?
>
>Is there a simplified/annotated version of the schema spec? To understand
>anything in the current spec I have to read it atleast 2-3 times.
>
Yes, it can be quite painful and time consuming sometimes. I think the 
sections you're looking for are the dreaded "Particle Derivation *** 
(Recurse)" sections. There are a few different types of these rules 
depending on the type of the group particle (all, choice or sequence) 
used in the base/restricted type but if you take for example [1] under 
the section "Schema Component Constraint: Particle Derivation OK 
(Choice:Choice -- RecurseLax)" you will have the following:

"For a choice group particle to be a ·valid restriction· of another 
choice group particle all of the following must be true:
1 R's occurrence range is a valid restriction of B's occurrence range as 
defined by Occurrence Range OK (§3.9.6);
2 There is a complete ·order-preserving· functional mapping from the 
particles in the{particles} of R to the particles in the {particles} of 
B such that each particle in the {particles} of R is a·valid 
restriction· of the particle in the {particles} of B it maps to as 
defined by Particle Valid (Restriction) (§3.9.6)."

Nr 2 above says that for a choice to be a valid restriction there needs 
to be a complete mapping from the particles in R to the particles in B.

I usually find the Primer [2] a good read although it doesn't have 
enough detail to cover complex cases. The answer to your question though 
is specified in the section about derivation by restriction [3].

Cheers,
/Eddie

[1] http://www.w3.org/TR/xmlschema-1/#coss-particle
[2] http://www.w3.org/TR/xmlschema-0
[3] http://www.w3.org/TR/xmlschema-0/#DerivByRestrict

>
>Thanks in anticipation,
>Vineet
>
>  
>
Received on Monday, 4 November 2002 18:00:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:35 GMT