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

Re: [RESEND] Derivation by restriction

From: Eddie Robertsson <erobertsson@allette.com.au>
Date: Tue, 02 Apr 2002 10:59:20 +1000
Message-ID: <3CA90268.9271161A@allette.com.au>
To: "Roger L. Costello" <costello@mitre.org>
CC: xmlschema-dev@w3.org, Simon.Cox@csiro.au
Hi Roger,

> > This appears to be pretty much how substitution groups were designed
> > to be used.
> Simon, I respectfully disagree.  That is NOT how substitution groups
> were designed to be used.  The intended purpose of substitution groups
> is to enable substitutability in **instance documents**.  You are
> attempting to perform substitution in the **schema**, which in the least
> is bad practice, if not outright incorrect (I need to check the spec on
> this).

Well, I definately wouldn't call this bad practice and it's most certainly
legal (See Jeni's posts on this issue). However, you're probably correct in
that this wasn't the intended usage for substitutionGroups. When I agreed
with Simon that this was the intended use for substitutionGroups I was
thinking in terms of extending types within the **schema** document and I
wasn't thinking about substitution in the **instance document**. I think the
way for example Simon has used substitutionGroups provides a good way for
extending types in XML Schema.
I've also found that since you can't really extend a xs:choice group (in the
extended type they will be a sequence of two choice groups) in XML Schema you
simulate an extension of a choice group by adding a new element to a


> As I read it, your example is defeating the whole purpose of
> substitution groups.  You have declared an abstract element _Head1 and
> then declared an element Member1 to be in the substitution group with
> _Head1.  Fine.  Then you created a complexType ContainHead1Type which
> contains _Head1.  Fine.  That's all you need!  Go no further!  Suppose
> an element, foo, is declared to be of type ContainHead1Type.  Then, **in
> an instance document** the content of <foo> must be any element declared
> to be in the substitution group with _Head1. That's what you want to
> happen. The philosophy of substutition groups is that the schema defines
> a bunch of components that an **instance document author** may utilize.
> Thus, substitution groups empower the instance document author with the
> ability to choose among "off the shelf components".  This is a very
> powerful design pattern.
> On the other hand, what your example is doing is something very
> different.  It is creating a second type, ContainMember1Type, which
> attempts to declare what element should substitute for the abstract
> _Head element.  Why?  If you really want Member1 to be the element then
> simply declare a complexType to contain a Member1 element.  I see no
> benefit to going through your indirection.  Further, I have serious
> doubts that this is even legal (although to be certain I need to consult
> the spec).  In general, in a restriction type you must retype everything
> in the parent type **verbatim**.  The only differences you may make are
> in the number of occurrences and/or the value space of parent elements.
> In your example you are trying to insert a totally new element in the
> child type.  It doesn't surprise me that MSXML gives an error with this.
> For more info on this topic see the section on variable content
> containers using abstract elements in:
> http://www.xfront.com/VariableContentContainers.pdf
> /Roger
> > *** However, both the cases here run afowl of the MSXML parser. ***
> > ("Invalid particle derivation by restriction").
> > Is MSXML wrong here, or am I missing something else?
> I had a look at your schemas and they both seem perfectly fine with me
> so my
> guess would be a bug in the MSXML parser. I see that Dare Obasanjo from
> Microsoft was sent this email as well so he'll probably check this out.
> If
> not, you can try to submit a bug on the MSXML newsgroup
> (microsoft.public.xml.msxml-webrelease) which is monitored by the MSXML
> team.
> Cheers,
> /Eddie
> > N.B. In the first case Member1Type is a restriction of Head1Type
> > by having a defined content model *** compared with an anyType ***.
> > In the second case Member2Type is a restriction of Head2Type
> > by restricting the cardinality of the content.
> >
> > ============
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <schema targetNamespace="http://xmml.ned.dem.csiro.au/my"
> > xmlns:my="http://xmml.ned.dem.csiro.au/my"
> > xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
> > attributeFormDefault="unqualified">
> >   <!-- -->
> >   <element name="_Head1" abstract="true"/>
> >   <!-- -->
> >   <complexType name="Member1Type">
> >     <sequence>
> >       <element name="foo" type="string"/>
> >     </sequence>
> >   </complexType>
> >   <!-- -->
> >   <element name="Member1" type="my:Member1Type"
> > substitutionGroup="my:_Head1"/>
> >   <!-- -->
> >   <complexType name="ContainHead1Type" abstract="true">
> >     <sequence>
> >       <element ref="my:_Head1"/>
> >     </sequence>
> >   </complexType>
> >   <!-- -->
> >   <complexType name="ContainMember1Type">
> >     <complexContent>
> >       <restriction base="my:ContainHead1Type">
> >         <sequence>
> >           <element ref="my:Member1"/>
> >         </sequence>
> >       </restriction>
> >     </complexContent>
> >   </complexType>
> > </schema>
Received on Monday, 1 April 2002 19:47:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:56 UTC