Model Group Definition

I am working at Lotus with Noah Mendelsohn, and while implementing a Schema
I came across the following situation, attempting to define a model group
that is any number of occurrences of a certain element:

 <xsd:group name="G">
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
   <xsd:element name="E" type="xsd:anyType" />
  </xsd:choice>
 </xsd:group>

 <xsd:element name="top">
  <xsd:complexType>
   <xsd:group ref="G" />
  </xsd:complexType>
 </xsd:element>

In fact, this allows the <top> element to include exactly one element <E
/>, using XSV to validate, instead of any number (E*) as you might assume.
Looking at part 1 of the Schema spec, the reason seems clear, in section
4.3.5 (http://www.w3.org/TR/xmlschema-1/#declare-namedModelGroup).  In a
model group definition, "A model group which is the {term} of a particle
corresponding to the all, choice or sequence among the [children]."  So,
when defining G, only the term of the <choice> in G is included, and not
the entire particle.  We ignore the minOccurs and maxOccurs, and are left
with exactly one element <E>.  Then the <top> element references this model
group, thus requiring exactly one element <E>.

Our workaround:  embed the <choice> in the definition of G within a
<sequence>:

 <xsd:group name="G">
  <xsd:sequence>
   <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:element name="E" type="xsd:anyType" />
   </xsd:choice>
  </xsd:sequence>
 </xsd:group>

Now, from the spec, we would expect the model group G to be defined as the
term of the <sequence>, which is the entire particle of the <choice>, and
thus is as before with the addition of the minOccurs and maxOccurs
attributes.  In fact, that is the way that XSV validates this schema, it
allows zero, one, or more elements <E> in the <top>.

While we think that we understand the behavior and believe that XSV is
accurate to the spec, we are left with two questions:
1. Is there some reason (was there already discussion?) to prefer that the
model group is only the term and not the particle?
2. If there is a reason, then wouldn't it at least be good to forbid the
minOccurs and maxOccurs attributes at the first level in the spec,
explicitly forbidding the ignored attributes, essentially turning this
example from a run-time error into a compile-time error?

Morris Matsa
IBM Corporation

Received on Tuesday, 21 November 2000 12:34:50 UTC