- From: Eddie Robertsson <eddie@allette.com.au>
- Date: Wed, 28 Nov 2001 10:01:39 +1100
- 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
> 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 UTC