W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2006

[Bug 3870] R-207: Question about wildcard restriction (1.0)

From: <bugzilla@wiggum.w3.org>
Date: Fri, 27 Oct 2006 20:54:21 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1GdYib-000193-1b@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3870

           Summary: R-207: Question about wildcard restriction (1.0)
           Product: XML Schema
           Version: 1.0 only
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: cmsmcq@w3.org
         QAContact: www-xml-schema-comments@w3.org


This issue arises from comments made by Dare Obasanjo at
http://lists.w3.org/Archives/Public/xmlschema-dev/2003Feb/0126.html
Michael Marchegay at
http://lists.w3.org/Archives/Public/xmlschema-dev/2003Oct/0084.html
and Miroslaw Kalinowski at 
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0037.html

Dare Obasanjo wrote:

  Is the following restriction valid: 

  BASE: 
    <xs:sequence minOccurs="0" maxOccurs="1"> 
      <xs:any namespace="##any" processContents="skip" 
        minOccurs="1" maxOccurs="unbounded"/> 
    </xs:sequence> 


  DERIVED: 
    <xs:sequence minOccurs="0" maxOccurs="1"> 
      <xs:element name="A" minOccurs="1" maxOccurs="unbounded" /> 
      <xs:element name="B" minOccurs="1" maxOccurs="unbounded" /> 
    </xs:sequence>

  The Microsoft schema validators consider it an invalid derivation
  for the following reasons (which we'd be interested in hearing
  counter arguments to):

  The schema author is trying to restrict a sequence containing a
  single particle to one containing multiple particles. The definition
  for a particle is given below taken from the W3C XML Schema
  recommendation at
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#cParticles

  "The particle schema component has the following properties:

  Schema Component: Particle 
   {min occurs} A non-negative integer. 
   {max occurs} Either a non-negative integer or unbounded. 
   {term}  One of a model group, a wildcard, or an element declaration. 

  In general, multiple element information item [children], possibly
  with intervening character [children] if the content type is mixed,
  can be &#183;validated&#183; with respect to a single particle. When the
  {term} is an element declaration or wildcard, {min occurs}
  determines the minimum number of such element [children] that can
  occur. The number of such children must be greater than or equal to
  {min occurs}. If {min occurs} is 0, then occurrence of such children
  is optional."

  The base type consists of a sequence containing a single particle
  with a {min occurs} of 0, a {max occurs} of unbounded and whose
  {term} is a wildcard.

  <xs:sequence minOccurs="0" maxOccurs="1"> 
    <xs:any namespace="##any" processContents="skip" 
      minOccurs="1" maxOccurs="unbounded"/> 
  </xs:sequence> 

  The derived type consists of a sequence containing two
  particles. Both particles have a {min occurs} of 0, a {max occurs}
  of unbounded and a {term} which is an element declaration.

    <xs:sequence minOccurs="0" maxOccurs="1"> 
      <xs:element name="A" minOccurs="1" maxOccurs="unbounded" /> 
      <xs:element name="B" minOccurs="1" maxOccurs="unbounded" /> 
    </xs:sequence>

  According to the rules for derivation by restriction of one sequence
  from another at
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#rcase-Recurse

  "For an all or sequence group particle to be a &#183;valid restriction&#183;
  of another group particle with the same {compositor} all of the
  following must be true:

    1 R's occurrence range is a valid restriction of B's occurrence
      range as defined by Occurrence Range OK (&#167;3.9.6).

    2 There is a complete &#183;order-preserving&#183; functional mapping from
      the particles in the {particles} of R to the particles in the
      {particles} of B such that all of the following must be true:

      2.1 Each particle in the {particles} of R is a &#183;valid
          restriction&#183; of the particle in the {particles} of B it maps
          to as defined by Particle Valid (Restriction) (&#167;3.9.6).

      2.2 All particles in the {particles} of B which are not
          mapped to by any particle in the {particles} of R are
          &#183;emptiable&#183; as defined by Particle Emptiable (&#167;3.9.6).

    NOTE: Although the &#183;validation&#183; semantics of an all group does
not
    depend on the order of its particles, derived all groups are
    required to match the order of their base in order to simplify
    checking that the derivation is OK.

    [Definition:] A complete functional mapping is order-preserving if
    each particle r in the domain R maps to a particle b in the range
    B which follows (not necessarily immediately) the particle in the
    range B mapped to by the predecessor of r, if any, where
    "predecessor" and "follows" are defined with respect to the order
    of the lists which constitute R and B. "

  The key statement to note is that the 'there is a complete order
  preserving functional mapping from the particles in the {particles}
  of R to the particles in the {particles} of B'. When trying to map a
  single particle with a wildcard term to two particles with element
  terms, this is not the case.

  Why this is necessary is made clearer in a simplified
  example. Consider the following base type

    <xs:sequence minOccurs="0" maxOccurs="1"> 
      <xs:any namespace="##any" processContents="skip" 
        minOccurs="1" maxOccurs="1"/> 
    </xs:sequence> 

  which one tries to derive from with the following

    <xs:sequence minOccurs="0" maxOccurs="1"> 
      <xs:element name="Element1" minOccurs="1" maxOccurs="1"
type="xs:string"/> 
      <xs:element name="Element2" minOccurs="1" maxOccurs="1"
type="xs:string"/> 
    </xs:sequence> 

  In the above case it is clear that the derived type is not a
  restriction of the base type. The same rules used to determine that
  the above case is invalid are the same ones used to declare the
  original attempt at derivation to be invalid.

See the following for Henry's answer and subsequent thread
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0057.html

In http://lists.w3.org/Archives/Public/xmlschema-dev/2003Oct/0084.html
Michael Marchegay writes:

  I find the text describing "pointless" particles (3.9.6 Constraints
  on Particle Schema Components - Schema Component Constraint:
  Particle Valid (Restriction)) a bit unclear.

  The first question I have is why does the text mixes XML Element
  Information Items and Schema Components?

  For example what is "The <sequence>'s {particles}"?

  Or what is a <all> whose {particles} is empty?  If an <all> with no
  <element> child is used within a <complexType>, isn't it supposed to
  mean that the content type of the complex type is empty?  If so is
  these a particle created for that <all> that could justify the
  reference to the {particles} property?

  Second question: is the sequence in the following complex type
  pointless?

    <complexType>
      <sequence>
        <element name="e"/>
      </sequence>
    </complexType>

  If yes, how could the following condition be verified?

      2.2.2.1 The particle within which this <sequence> appears has
              {max occurs} and {min occurs} of 1.

  If no, does the following <complexType> express a valid complex type
  definition?

      <complexType>
        <complexContent>
          <restriction base="anyType">
            <all>
              <element name="e"/>
            </all>
          </restriction>
        </complexContent>
      </complexType>

See
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003OctDec/0023.html
for Henry Thompson's response and subsequent thread.

In
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0037.html
Miroslaw Kalinowski raises a related issue (or the same issue?).

The same issue is raised against XML Schema 1.1 in bug 2199.  In 1.1,
the issue was resolved by deleting the constructive rules for checking
restrictions.
Received on Friday, 27 October 2006 20:54:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:11 GMT