Re: <group> element's attributes

> "Henry S. Thompson" wrote:
>
> > We had to choose which took effect, the referring <group ref="..."
> > .../>'s min- and maxOccurs, or the referred to's actual group (the
> > all/choice/sequence child of <group>).  We decided to go with the
> > referring one -- this seems to be what's wanted nine times out of ten,
> > although _not_ always -- suggestions for improvements for the next
> > version welcome.
>
> That makes sence.
> How about solving the problem using presedence so that the minOccurs and
> maxOccurs on the <xsd:group ref=".."/> always have higher priority that
the
> minOccurs and maxOccurs on the child of the group?

Why not apply both?  Decide that
  <group name="n">x</group>
in the future XML Schema syntax desugars into
  <group name="n"><sequence>x</sequence></group>
in the current Rec XML Schema syntax.

> For example if you define your group as:
>
> <xsd:group name="myGroup">
>     <xsd:sequence minOccurs=1 maxOccurs="5">
>         ...
>     </xsd:sequence>
> </xsd:group>
>
> and you have two references:
>
> <xsd:group ref="myGroup"/>
> In this case the minOccurs and maxOccurs on the <xsd:sequence> child
above will
> apply.

Still the same.  It would be 1-5.

>
> <xsd:group ref="myGroup" minOccurs="1" maxOccurs="1"/>
> In this case the minOccurs and maxOccurs on the reference will apply.
>

Instead, this would again be 1-5.  Exactly one of a group that allows 1-5
times,
means 1-5 times.

> Note that in this case you can't use the default values of 1 for
minOccurs and
> maxOccurs on the reference. Instead you have to look back at the
declaration
> which is referenced and check the minOccurs and maxOccurs. If they have a
value
> here these values should be applied, otherwise they should default to 1.
I guess
> this will complicate the validation though...

It seems to me to be odd that specifying minOccurs and maxOccurs as the
default values
is different than letting them default.  I'm not sure that the distinction
is visible.

> <stuff deleted>

> Cheers.
> /Eddie

Another example, a zipcode must be exactly five digits:
<xsd:group name="zipcode">
 <xsd:sequence minOccurs="5" maxOccurs="5">
  <def-of-digit />
 </xsd:sequence>
</xsd:group>

An optional zipcode is zero or one zipcodes:
<xsd:group ref="zipcode" minOccurs="0" maxOccurs="1" />

Using both constraints means that an optional zipcode becomes either
exactly
zero digits or exactly five digits.  This seems natural to me.  The Rec
allows
this behavior but forces me to add the explicit extra <sequence> to explain
that
I really want this behavior.

I assume that the WG has thought about this and decided that it's not clear
what
will happen when looking at the schema and thus we have the Rec with all
the same
behavior allowed but no allowed min/max on the top component in the group
and
thus no confusion over what is applied.  I think this (Rec) solution is ok
too.

Received on Tuesday, 8 May 2001 13:59:53 UTC