Unique Particle Attribution with Choice groups that contain Sequence Groups

My understanding is that Unique Particle Attribution constraint is so that
parsers do not have to lookahead.

If I define a complex type as follows:
<xsd:complexType name="ChoiceOfSequences1">
  <xsd:choice>
     <xsd:sequence>
         <xsd:element name="a" type="typeOfA"/>
         <xsd:element name="b" type="typeOfB"/>
         <xsd:element name="d" type="typeOfD"/>
      </xsd:sequence>
      <xsd:sequence>
          <xsd:element name="a" type="typeOfA"/>
          <xsd:element name="c" type="typeOfC"/>
      </xsd:sequence>
    </xsd:choice>
  </xsd:complexType>
is this permitted (a legal type definition)?

I could imagine the answer is yes, because a parser doesn't have
to look ahead during parsing.

I could imagine the answer is no in the case where the equivalence
classes of  c  and of   b   are not completely independent, but only
because
the first sequence requires that  d  follow  b.

If this second thought is the one intended by the working group,
shouldn't Structures appendix E say something
about this under 'Unique Particle Attribution'?

Here is a different case:
If I define a complex type as follows:
<xsd:complexType name="ChoiceOfSequences2">
  <xsd:choice>
     <xsd:sequence>
         <xsd:element name="a" type="typeOfA1"/>
         <xsd:element name="b" type="typeOfB"/>
      </xsd:sequence>
      <xsd:sequence>
          <xsd:element name="a" type="typeOfA2"/>
          <xsd:element name="c" type="typeOfC"/>
      </xsd:sequence>
    </xsd:choice>
  </xsd:complexType>
is this permitted (a legal type definition)?

Does this depend on whether there is a common parent
type for typeOfA1 and typeOfA2 other than the ur-type?
(Since if there was, and the xsi:type attribute was not used
on the a element in the instance document with a value
of either typeOfA1 or typeOfA2, the parser would have to
look ahead before determining which branch of the choice
was being processed).

I think the general problem related to choices (which may
contain choices, which may contain choices) which contain
sequences.

Here is a third case:
If I define a complex type as follows:
<xsd:complexType name="ChoiceOfChoices3">
  <xsd:choice>
     <xsd:choice>
         <xsd:element name="a" type="typeOfA1"/>
         <xsd:element name="b" type="typeOfB"/>
      </xsd:choice>
      <xsd:choice>
          <xsd:element name="a" type="typeOfA2"/>
          <xsd:element name="c" type="typeOfC"/>
      </xsd:choice>
    </xsd:choide>
  </xsd:complexType>
is this permitted?  I don't think it is, because a choice
of choices is like flattening to one choice, and then
there are 2 different types that can appear with element
a.  (Appendix E does rule out this if the user had it
flattened, and in Section 5.7 on model groups, I think
this is covered by Element Declarations Consistent).
But this still seems to me that a "Also see..." in Appendix
E should cover this case.

I guess I'm asking for clarification of these examples now,
and also that Appendix E be more complete in the
next spec working draft.

Thank you,
Bob Schloss

IBM T.J. Watson Research Center
Yorktown Heights, NY, USA

Received on Wednesday, 10 May 2000 19:47:11 UTC