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@w... =
[mailto:xmlschema-dev-request@w...]
> On Behalf Of richard.liu@u...
> Sent: Monday, February 13, 2006 6:56 AM
> To: mike@s...; george@o...
> Cc: xmlschema-dev@w...
> 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@w... =
[mailto:xmlschema-dev-request@w...]
> On Behalf Of Michael Kay
> Sent: Monday, February 13, 2006 12:33
> To: 'George Cristian Bina'; Liu, Richard
> Cc: xmlschema-dev@w...
> 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@w...
> > [mailto:xmlschema-dev-request@w...] On Behalf Of George
> > Cristian Bina
> > Sent: 13 February 2006 09:34
> > To: richard.liu@u...
> > Cc: xmlschema-dev@w...
> > 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
> > www.---.com
> >
> >
> > richard.liu@u... 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@m...
> > >
> > >
> > >
> > > Richard R. Liu
> > > UBS AG
> > > VZA2 - 4.140 IVHS-L2V
> > > Postfach
> > > CH-8098 Z=FCrich
> > > Switzerland
> > >
> > > Tel.  +41-44-238 48 82
> > > Email richard.liu@u...
> > >
> >
> >
> 
> 
> 


From ralf.lammel@m... Mon Feb 13 20:23:49 2006
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1F8kEf-0002tO-Nb
	for xmlschema-dev@listhub.