Re: [RESEND] Derivation by restriction

Hi Simon,


> In our schemas we have a /lot/ of cases following a general pattern:
>
> 1.  Declare an element to act as head of substitition group;
> 2.  Declare non-abstract elements in the substitution group,
> with a type derived from the type of the head by restriction;
> 3.  Define a complex type which contains the abstract head element;
> 4.  Define a restriction of the container which specifies that
> a particular concrete member element is present.
>
> This appears to be pretty much how substitution groups were designed to be
> used.

That's pretty much my understanding as well.

> *** 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>
>
> ============
>
> <?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">
>   <!-- -->
>   <complexType name="Head2Type">
>     <sequence>
>       <element name="foo" type="string" maxOccurs="unbounded"/>
>     </sequence>
>   </complexType>
>   <!-- -->
>   <element name="_Head2" type="my:Head2Type" abstract="true"/>
>   <!-- -->
>   <complexType name="Member2Type">
>     <complexContent>
>       <restriction base="my:Head2Type">
>         <sequence>
>           <element name="foo" type="string"/>
>         </sequence>
>       </restriction>
>     </complexContent>
>   </complexType>
>   <!-- -->
>   <element name="Member2" type="my:Member2Type"
> substitutionGroup="my:_Head2"/>
>   <!-- -->
>   <complexType name="ContainHead2Type" abstract="true">
>     <sequence>
>       <element ref="my:_Head2"/>
>     </sequence>
>   </complexType>
>   <!-- -->
>   <complexType name="ContainMember2Type">
>     <complexContent>
>       <restriction base="my:ContainHead2Type">
>         <sequence>
>           <element ref="my:Member2"/>
>         </sequence>
>       </restriction>
>     </complexContent>
>   </complexType>
>   <!-- -->
> </schema>
>
> =========
> _____
> [This mail represents part of a discussion of work in progress
> and should not be used for any purpose without my permission.]
> _____
> Simon.Cox@csiro.au  CSIRO Exploration & Mining
> 26 Dick Perry Avenue, Kensington WA 6151
> PO Box 1130, Bentley WA 6102  AUSTRALIA
> T: +61 (8) 6436 8639  F: +61 (8) 6436 8555  C: +61 (4) 0330 2672
> http://www.csiro.au/page.asp?type=resume&id=CoxSimon
>
> > -----Original Message-----
> > From: Priya Lakshminarayanan [mailto:priyal@microsoft.com]
> > Sent: Tuesday, 19 March 2002 4:03 AM
> > To: Jeni Tennison; Dare Obasanjo
> > Cc: Xmlschema-Dev (E-mail)
> > Subject: RE: [RESEND] Derivation by restriction
> >
> >
> > Yes, the primer is in error. Attached is the mail thread regarding the
> > discussion. This was supposed to raised as an errata against
> > the primer.
> >
> >
> > Thanks,
> > Priya
> >
> > -----Original Message-----
> > From: Jeni Tennison [mailto:jeni@jenitennison.com]
> > Sent: Saturday, March 16, 2002 3:22 AM
> > To: Dare Obasanjo
> > Cc: Xmlschema-Dev (E-mail)
> > Subject: Re: [RESEND] Derivation by restriction
> >
> > Hi Dare,
> >
> > > NOTE: The above constraint on {type definition}
> > > <http://www.w3.org/TR/xmlschema-1/#type_definition> means that in
> > > deriving a type by restriction, any contained type definitions must
> > > themselves be explicitly derived by restriction from the
> > > corresponding type definitions in the base definition.
> > >
> > > However this runs contrary to both the text in 'Essential XML Quick
> > > Reference' on XML Schema xs:restriction (p. 337) and the example in
> > > the XML Schema Primer[1] which imply that simply defining the
> > > contained type again in a derived type without the contained type
> > > deriving by restriction is allowable. XML Spy also validates both
> > > schemas.
> > >
> > > So are we interpreting the recommendation correctly or not?
> >
> > For what it's worth, I think that you are, and that the Primer is in
> > error.
> >
> > Cheers,
> >
> > Jeni
> >
> > ---
> > Jeni Tennison
> > http://www.jenitennison.com/
> >
> >