[XMLSCHEMA-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Derivation by restriction wrt to type inheritance

From: Eddie Robertsson <eddie@allette.com.au>
Date: Wed, 28 Nov 2001 10:01:39 +1100
Message-ID: <3C041B53.CE00C844@allette.com.au>
To: Jeni Tennison <jeni@jenitennison.com>
CC: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>, Martin Bernauer <bernauer@dke.uni-linz.ac.at>, xmlschema-dev@w3.org
Re: Derivation by restriction wrt to type inheritance
> or perhaps misread and thought that Object was an element rather than a
> type).

Arrgghh! That's exactly what I did so thanks for clearing that out.

> As you know, when you restrict complex content you have to list all
> the elements and attributes that you want to *permit*. So having an
> empty complex type definition is equivalent to not allowing any
> content or any attributes.

Sure, this makes sence now....

> > 2) My second reason is because (from what I can understand) in the
> > above restriction the intent is to use person elements instead of
> > entry elements. Doesn't the rules on restriction say that for this
> > to be valid then the type of the person element must be derived by
> > _restriction_ from the type of the entry element. In this case the
> > type of the person element (Person) is derived by _extension_ from
> > the type of the entry element (Object).
>
> When you have a substitution group, the particle that refers to the
> head of the substitution group (i.e. the event element) is effectively
> substituted for an xs:choice that lists all the members of the
> substitution group. So effectively the List type is as follows:
>
> <xs:complexType name="List">
>   <xs:sequence minOccurs="0" maxOccurs="unbounded">
>     <xs:choice>
>       <xs:element ref="person" />
>       ... any other members of the entry substitution group ...
>     </xs:choice>
>   </xs:sequence>
> </xs:complexType>
>
> As you can see, you can validly derive by restriction to the
> personList content model from that expanded xs:choice, just by cutting
> out a few of the choices.
>
> So you can replace an element with an element from its substitution
> group no matter what derivation method was used to derive the type of
> the element.

Thanks again for clearing this out for me. I've read the spec about the
substitutionGroups but never really understood how it worked so this was a
big help. I can now see why Henry's example was indeed a valid
restriction.

Cheers,
/Eddie
Received on Tuesday, 27 November 2001 17:54:53 GMT

Subscribe to the Stylus Scoop newsletter for helpful XML tips and tutorials.
Email
First Name
Last Name
Company

Download Stylus Studio 6 XML Enterprise Edition

Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.