RE: Model Group Definition

Here's our reasoning:

[1] says "A model group which is the {term} of a particle corresponding to
the ... choice."
Not:     "A model group which is the {particle}           corresponding to
the ... choice."

The particle corresponding to the choice includes it's minOccurs (0),
maxOccurs (unbounded), and term (the element E). [See Particle Details,
http://www.w3.org/TR/xmlschema-1/#Particle_details]

The "{term} of a particle" should only include the element <E>.  Then 'top'
expands to (without the workaround):

<xsd:element name="top">
  <xsd:complexType>
     <xsd:choice>
          <xsd:element name="E" type="xsd:anyType" />
     </xsd:choice>
  </xsd:complexType>
</xsd:element>

If this explanation is correct, then XSV acts correctly, and allowing the
minOccurs and maxOccurs which are ignored seems to be misleading.

Morris



"Asir S Vedamuthu" <asirv@webmethods.com> on 11/21/2000 01:20:58 PM

To:   Morris Matsa/Somers/IBM@IBMUS, <www-xml-schema-comments@w3.org>
cc:
Subject:  RE: Model Group Definition



Using your example and text from the CR drafts,
[1] "A model group which is the {term} of a particle corresponding to the
all, choice or sequence among the [children] (there must be one)"
-
http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#declare-namedModelGroup

Element 'top' expands to,

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

>> Our workaround: ..
Workaround is not required

>> that XSV is accurate to the spec, ..
May be not .. wait for a response from Henry S Thompson

I would appreciate if you could explain what part of text in [1] is
ambiguous or misleading?

Regards, Asir S Vedamuthu
-----Original Message-----
From: www-xml-schema-comments-request@w3.org
[mailto:www-xml-schema-comments-request@w3.org]On Behalf Of Morris Matsa
Sent: Tuesday, November 21, 2000 12:33 PM
To: www-xml-schema-comments@w3.org
Subject: 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 14:22:07 UTC