Restriction+choice+substitutionGroup: rcase-RecurseLax insufficie nt?

[Now that I look at what I have written below, it looks like a case for a
derivation of a choice group from a single element, which is forbidden.  But
then, what are substitution groups if not that?  Maybe the following is a
good case for elt <- choice derivations.]


Here is my scenario, abstracted for the reader.  Type A defines a choice of
any number of X or Y as follows:

  <xsd:complexType name="A">
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element ref="X"/>
          <xsd:element ref="Y"/>
        </xsd:choice>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

(It doesn't matter what X and Y are defined as, let's just say they are
empty for arguments sake.)

I then define several types X1, X2 and X3, all of which are in the
substitution group headed by X.  These are valid substitions for X, so we
can get a document that contains all of these new elements as follows:

  <A><X1/><Y/><X1/><X3/><X1/></A>

Now I want to define a restriction, B, of this that only allows certain
substitutions for X, only X1 and X2 are valid.  Unfortunately the following
schema is invalid by the rules in rcase-RecurseLax:

  <!-- INVALID SCHEMA -->
  <xsd:complexType name="B">
    <xsd:complexContent>
      <xsd:restriction base="A">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element ref="X1"/>
          <xsd:element ref="X2"/>
          <xsd:element ref="Y"/>
        </xsd:choice>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

I would even be happy with the following if necessary:

  <!-- INVALID SCHEMA -->
  <xsd:complexType name="B">
    <xsd:complexContent>
      <xsd:restriction base="A">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:choice>
            <xsd:element ref="X1"/>
            <xsd:element ref="X2"/>
          </xsd:choice>
          <xsd:element ref="Y"/>
        </xsd:choice>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

On the other hand, the rules under rcase-MapAndSum allow for a sequence
restriction of a choice to be built from substitutions as follows:

  <xsd:complexType name="B">
    <xsd:complexContent>
      <xsd:restriction base="A">
        <xsd:sequence>
          <xsd:element ref="X1" minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="X2" minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="Y" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>

However, this doesn't allow for the full mix of elements that the choice
group above would allow.

I would suggest that rcase-RecurseLax be amended to something like:

    2 There is an ·order-preserving· functional mapping from the particles
in the {particles} of R to the particles in the {particles} of B, where each
particle in the {particles} of R may map to the same particle in the
{particles} of B, such that each particle in the {particles} of R is a
·valid restriction· of the particle in the {particles} of B it maps to as
defined by Particle Valid (Restriction) (§3.9.6).
    3 Where multiple particles in the {particles} of R map to the one
particle in the {particles} of B, the pair of the sum of the {min occurs}
and the sum of the {max occurs} of each of the particles in the {particles}
of R must be a valid restriction of the occurrence range for the mapped
particle from the {particles} of B as defined by Occurrence Range OK
(§3.9.6).

Of course, that would change if the elt <- choice restriction were allowed,
there would just be a pointer to that specification, which would look like
clause 3 here.

Regards,
Martin