[
Lists Home |
Date Index |
Thread Index
]
Thanks both Henry and Eric. It does seem to me that the confusion caused
by this rule is at least as great as the confusion that would ensue
without it, but I am grateful for the information. Just another special
case to tuck away, which is how we all make jobs for each other. ;-}
HT's note on the difference between an iterated choice and a choice of
iterations is also to the point, earlier in the thread. I'm surprised
this slipped by the rest of us.
Bob Foster
http://xmlbuddy.com/
Henry S. Thompson wrote:
>Bob Foster <bob@objfac.com> writes:
>
>
>
>>I'm a bit puzzled by this. I can see why he can't have a
>>minOccurs/maxOccurs on the group item as specified but why not on the
>>choice nested in the group. This looks legal to me and I am curious
>>what processors do not accept it.
>>
>>
>
>On balance the reasoning the XML Schema WG went with was roughly this:
>
> 1) Named model groups will be most useful if different references to
> them can have different min/max values;
> 2) Allowing min/max on both references _and_ on the top level group
> in the named group definition, e.g.
>
> . . .
> <xs:group ref="myGroup" minOccurs="1" maxOccurs="10"/>
> . . .
>
> <xs:group name="myGroup">
> <xs:choice minOccurs="2" maxOccurs="4">
> . . .
> </xs:choice>
> </xs:group>
>
> would be _very_ confusing and difficult to explain;
> 3) So we rule out min/max on the top group in a named model group defn.
>
>Note also that
>
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> <xs:element name="e1"/>
> <xs:element name="e2"/>
> <xs:element name="e3"/>
> </xs:choice>
>
>means something _quite_ different from
>
> <xs:choice>
> <xs:element name="e1" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element name="e2" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element name="e3" minOccurs="0" maxOccurs="unbounded"/>
> </xs:choice>
>
>For example, the first allows e1 e2 e1
>
>The second does not.
>
>ht
>
>
|
