W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2006

RE: E rcase-RecurseLax.1: Group's occurrence range, (1,unbounded), is not a valid restriction of base group's occurrence range, (1,1).

From: Ralf Lammel <Ralf.Lammel@microsoft.com>
Date: Mon, 13 Feb 2006 12:17:00 -0800
Message-ID: <1152E22EE8996742A7E36BBBA7768FEE089C0773@RED-MSG-50.redmond.corp.microsoft.com>
To: <richard.liu@ubs.com>, <mike@saxonica.com>, <george@oxygenxml.com>
Cc: <xmlschema-dev@w3.org>

But hold on ...

1. <sequence/> is not pointless (in an algebraic sense certainly not) *when* placed as a branch of a choice simply because it makes the entire choice optional (if it wasn't yet before).

2. Hence, I don't see why Xerces is doing the right thing when it accepts the proposed fix with the empty sequence as part of the restricted choice. For curiosity, I tried some other validator, and indeed, it would accept this fix.

3. Or was the idea to add the empty sequence to *both* base type and restricted type? But this wouldn't be semantics-preserving either, not in even in the special case posted. (The base-type semantics did not comprise the empty content as far as I can see.)

4. I do agree in so far that we are suffering here from a really wild semantics of subtyping choices in the context of restriction here. Let's simplify your example to get rid of feature interaction with groups. This scheme of restriction still works:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="a1" type="xs:string"/>
  <xs:element name="a2" type="xs:string"/>
  <xs:element name="b" type="xs:string"/>
  <xs:element name="c" type="xs:string"/>
  <xs:complexType name="baseType">
    <xs:choice>
      <xs:choice maxOccurs="unbounded">
        <xs:element ref="a1"/>
        <xs:element ref="a2"/>
      </xs:choice>
      <xs:element ref="b"/>
      <xs:element ref="c"/>
    </xs:choice>
  </xs:complexType>
  <xs:complexType name="restrictedType">
    <xs:complexContent>
      <xs:restriction base="baseType">
        <xs:choice>
          <xs:choice maxOccurs="unbounded">
            <xs:element ref="a1"/>
            <xs:element ref="a2"/>
          </xs:choice>
          <xs:element ref="b"/>
        </xs:choice>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
</xs:schema>

So the restriction has indeed removed one branch of the choice.
This schema still validates fine.
If we now tried to remove one more branch ...

  <xs:complexType name="restrictedType">
    <xs:complexContent>
      <xs:restriction base="baseType">
        <xs:choice>
          <xs:choice maxOccurs="unbounded">
            <xs:element ref="a1"/>
            <xs:element ref="a2"/>
          </xs:choice>
          <!-- <xs:element ref="b"/> -->
        </xs:choice>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

... but then we run into the sort of problem of the OP.

The problem is indeed that the outer choice becomes sort of pointless.
Algebraically, it makes *totally* sense that the above (2nd) restriction is treated the same as the following (with the pointless choice eliminated):

  <xs:complexType name="restrictedType">
    <xs:complexContent>
      <xs:restriction base="baseType">
        <xs:choice maxOccurs="unbounded">
          <xs:element ref="a1"/>
          <xs:element ref="a2"/>
        </xs:choice>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

Algebraically, it is not acceptable that this restriction is not valid with regard to the original base type anymore. (And again, algebraically, it is not acceptable "to make it work" by adding an empty sequence branch.) So if the XSD spec or the XSD implementation or both doesn't/don't know about the algebra of regular expressions (or it least does not use it for the notion of subtyping in restriction), then we can try to fix this as follows:

a) We define the impossible element declaration:

  <xs:element name="impossible" final="#all">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="impossible"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

BTW, the fact that this element declaration is definable is a sort of interesting property of XSD anyhow, but it really helps here.

b) We define the base type to also comprise an impossible branch:

  <xs:complexType name="baseType">
    <xs:choice>
      <xs:element ref="impossible"/>
      <xs:choice maxOccurs="unbounded">
        <xs:element ref="a1"/>
        <xs:element ref="a2"/>
      </xs:choice>
      <xs:element ref="b"/>
      <xs:element ref="c"/>
    </xs:choice>
  </xs:complexType>

Again, one might argue that the impossible element is *kind* of pointless but XSD implementations are not allowed to see this (and optimize the particle away) because the spec doesn't identify this sort of pointlessness.

c) Hence, the offending restriction does not contain any pointless choice anymore, and the following works:

  <xs:complexType name="restrictedType">
    <xs:complexContent>
      <xs:restriction base="baseType">
        <xs:choice>
          <xs:element ref="impossible"/>
          <xs:choice maxOccurs="unbounded">
            <xs:element ref="a1"/>
            <xs:element ref="a2"/>
          </xs:choice>
        </xs:choice>


Regards,
Ralf Laemmel
Webdata/XML, Microsoft
http://homepages.cwi.nl/~ralf/


> -----Original Message-----
> From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
> On Behalf Of richard.liu@ubs.com
> Sent: Monday, February 13, 2006 6:56 AM
> To: mike@saxonica.com; george@oxygenxml.com
> Cc: xmlschema-dev@w3.org
> Subject: RE: E rcase-RecurseLax.1: Group's occurrence range,
> (1,unbounded), is not a valid restriction of base group's occurrence
> range, (1,1).
> 
> 
> George, Michael,
> 
> Thanks to both of you for your insights.  As usual, you're both right.
> Adding the pointless sequence satisfies Xerces, as George suggests.  And,
> as Michael suggests, this is totally counter-intuitive.
> 
> Regards,
> Richard
> 
> -----Original Message-----
> From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
> On Behalf Of Michael Kay
> Sent: Monday, February 13, 2006 12:33
> To: 'George Cristian Bina'; Liu, Richard
> Cc: xmlschema-dev@w3.org
> Subject: RE: E rcase-RecurseLax.1: Group's occurrence range,
> (1,unbounded), is not a valid restriction of base group's occurrence
> range, (1,1).
> 
> 
> Surely adding a pointless sequence to the choice can't affect the outcome,
> because a pointless sequence is ignored? But I'm not sure at what point in
> the algorithm pointless particles are supposed to be discarded.
> 
> Anyway, this seems to be one of the cases where the algorithm in Schema
> Part
> 1 is plain wrong.
> 
> Michael Kay
> http://www.saxonica.com/
> 
> 
> > -----Original Message-----
> > From: xmlschema-dev-request@w3.org
> > [mailto:xmlschema-dev-request@w3.org] On Behalf Of George
> > Cristian Bina
> > Sent: 13 February 2006 09:34
> > To: richard.liu@ubs.com
> > Cc: xmlschema-dev@w3.org
> > Subject: Re: E rcase-RecurseLax.1: Group's occurrence range,
> > (1,unbounded), is not a valid restriction of base group's
> > occurrence range, (1,1).
> >
> >
> > Hello Richard,
> >
> > Xerces is right to report that error as I read the spec. To have this
> > correct you need to add an empty sequence as below:
> > <xs:choice>
> >    <xs:group ref="a-Group" maxOccurs="unbounded"/>
> >    <xs:sequence/>
> > </xs:choice>
> > Otherwise the main choice particle is ignored according to
> > http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict
> > See 2, 2.2, 2.2.2, 2.2.2.2.1.
> > ***
> > 2.2 Any pointless occurrences of <sequence>, <choice> or <all> are
> > ignored, where pointlessness is understood as follows:
> > <choice>
> > One of the following must be true:
> > 2.2.2 All of the following must be true:
> > 2.2.2.1 The particle within which this <choice> appears has
> > {max occurs}
> > and {min occurs} of 1.
> > 2.2.2.2 One of the following must be true:
> > 2.2.2.2.1 The <choice>'s {particles} has only one member.
> > ***
> >
> > and the restricted type is equivalent with only
> > <xs:group ref="a-Group" maxOccurs="unbounded"/>
> >
> > that is equivalent with
> >
> > <xs:choice maxOccurs="unbounded">
> >    <xs:element ref="a1"/>
> >    <xs:element ref="a2"/>
> >    <xs:element ref="a3"/>
> > </xs:choice>
> >
> > and this cannot restrict
> >
> > <xs:choice>
> >    <xs:group ref="a-Group" maxOccurs="unbounded"/>
> >    <xs:element ref="b"/>
> > </xs:choice>
> >
> > as the choice here has minOccurs and maxOccurs equal with 1.
> >
> > Best Regards,
> > George
> > ---------------------------------------------------------------------
> > George Cristian Bina
> > <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> > http://www.oxygenxml.com
> >
> >
> > richard.liu@ubs.com wrote:
> > > I have the following W3C XML schema:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="qualified" targetNamespace="http://www.ubs.com/
> > > namespace/wbml-render" xmlns="http://www.ubs.com/namespace/wbml-
> > > render" xmlns:wbr="http://www.ubs.com/namespace/wbml-render">
> > >      <xs:element name="a" type="xs:string"/>
> > >      <xs:element name="a1" type="xs:string"/>
> > >      <xs:element name="a2" type="xs:string"/>
> > >      <xs:element name="a3" type="xs:string"/>
> > >      <xs:element name="b" type="xs:integer"/>
> > >      <xs:group name="a-Group">
> > >          <xs:choice>
> > >              <xs:element ref="a1"/>
> > >              <xs:element ref="a2"/>
> > >              <xs:element ref="a3"/>
> > >          </xs:choice>
> > >      </xs:group>
> > >      <xs:complexType name="groupBaseType">
> > >          <xs:choice>
> > >              <xs:group ref="a-Group" maxOccurs="unbounded"/>
> > >              <xs:element ref="b"/>
> > >          </xs:choice>
> > >      </xs:complexType>
> > >      <xs:complexType name="groupRestrictedType">
> > >          <xs:complexContent>
> > >              <xs:restriction base="groupBaseType">
> > >                  <xs:choice>
> > >                      <xs:group ref="a-Group" maxOccurs="unbounded"/>
> > >                  </xs:choice>
> > >              </xs:restriction>
> > >          </xs:complexContent>
> > >      </xs:complexType>
> > >      <xs:complexType name="baseType">
> > >          <xs:choice>
> > >              <xs:element ref="a" maxOccurs="unbounded"/>
> > >              <xs:element ref="b"/>
> > >          </xs:choice>
> > >      </xs:complexType>
> > >      <xs:complexType name="restrictedType">
> > >          <xs:complexContent>
> > >              <xs:restriction base="baseType">
> > >                  <xs:choice>
> > >                      <xs:element ref="a" maxOccurs="unbounded"/>
> > >                  </xs:choice>
> > >              </xs:restriction>
> > >          </xs:complexContent>
> > >      </xs:complexType>
> > > </xs:schema>
> > >
> > > The a-Group is a choice of three elements.  The
> > groupBaseType is a choice of either one to unbounded many
> > instances of a-Group, or of the element b.  I want to define
> > another complex type as a restriction of the groupBaseType.
> > It should not allow b.
> > >
> > > In Oxygen 7 I receive the following two error messages.
> > >
> > > SystemID: /Applications/oxygen/Untitled1.xsd
> > > Location: 21:48
> > > Description: E rcase-RecurseLax.1: Group's occurrence
> > range, (1,unbounded), is not a valid restriction of base
> > group's occurrence range, (1,1).
> > > URL: http://www.w3.org/TR/xmlschema-1/#rcase-RecurseLax
> > >
> > > SystemID: /Applications/oxygen/Untitled1.xsd
> > > Location: 21:48
> > > Description: E derivation-ok-restriction.5.4.2: Error for
> > type 'groupRestrictedType'.  The particle of the type is not
> > a valid restriction of the particle of the base.
> > > URL: http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction
> > >
> > > Evidently, based on the second example using baseType and
> > restrictedType, the error messages pertain to the fact that I
> > am using a group, but I don't understand what is wrong.  Can
> > anybody shed light on the error?
> > >
> > > Regards,
> > > Richard
> > >
> > > Richard R. Liu
> > > Gundeldingerstr. 171
> > > CH-4053 Basel
> > > Switzerland
> > >
> > > Tel. +41 (61) 361 3275
> > > Email richard.liu@mac.com
> > >
> > >
> > >
> > > Richard R. Liu
> > > UBS AG
> > > VZA2 - 4.140 IVHS-L2V
> > > Postfach
> > > CH-8098 Zürich
> > > Switzerland
> > >
> > > Tel.  +41-44-238 48 82
> > > Email richard.liu@ubs.com
> > >
> >
> >
> 
> 
> 
Received on Monday, 13 February 2006 20:17:15 GMT

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