- From: Asir S Vedamuthu <asirv@webmethods.com>
- Date: Tue, 21 Nov 2000 20:21:50 -0500
- To: "Morris Matsa" <mmatsa@us.ibm.com>
- Cc: <www-xml-schema-comments@w3.org>
You are *CORRECT*. Glad, you spotted it. >> 1. Is there some reason (was there already discussion?) to prefer that the model group is only the term and not the particle? DON'T KNOW why? May be, to get around 'Unique Particle Attribution Constraint'. But, it is counter-intuitive. >> 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? If there is a reason, there is ANOTHER alternate way to accomplish it, [A] - Forbid minOccurs and maxOccurs attributes in the XML rep of Model Group. ie, <group id = ID name = NCName ref = QName {any attributes with non-schema namespace . . .}> Content: (annotation? , (all | choice | sequence)?) </group> [B] - Change the mapping in Section 4.3.5 FROM {model group} <== "A model group which is the {term} of a particle corresponding to the all, choice or sequence among the [children] (there must be one)" TO {model group} <== "A model group which is the particle corresponding to the all, choice or sequence among the [children] (there must be one)" Benefits, intuitive and WYSIWYG; requires less prose to explain this; no more iff .. 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 2:20 PM To: Asir S Vedamuthu Cc: www-xml-schema-comments@w3.org Subject: 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 20:09:27 UTC