- From: <Simon.Cox@csiro.au>
- Date: Mon, 25 Mar 2002 15:02:44 +0800
- To: priyal@microsoft.com, jeni@jenitennison.com, dareo@microsoft.com
- Cc: xmlschema-dev@w3.org, John.Herring@oracle.com, portele@interactive-instruments.de
Priya - thanks for attaching the old mail thread. This is directly relevant as I am working with the initiative which triggered the issue - Geography Markup Language (from OpenGIS Consortium). We are now ridding our schemas of cases where the type of a substitution group member extended the type of the substitution group head, while the container type was derived by restriction. **However**, we are not out of the woods yet, in regards to MSXML's rigorous implementation of derivation-by-restriction. 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. *** 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? 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/ > >
Received on Monday, 25 March 2002 02:12:27 UTC