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

RE: [RESEND] Derivation by restriction

From: <Simon.Cox@csiro.au>
Date: Mon, 25 Mar 2002 15:02:44 +0800
Message-ID: <116D27C8E12BD411B3AB00B0D022B0B8010E54B3@yate.wa.csiro.au>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:30 GMT