Unique Particle Attribution with Choice groups that contain Sequence Groups

• From: <rschloss@us.ibm.com>
• Date: Wed, 10 May 2000 19:42:22 -0400
• To: www-xml-schema-comments@w3.org
• Message-ID: <852568DB.00823DF7.00@D51MTA03.pok.ibm.com>

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