W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2008

RE: inquiry into the <choice> element behavior

From: Den Tandt, Andy <AndyDT@enfocus.com>
Date: Fri, 31 Oct 2008 17:33:05 +0100
Message-ID: <2EBA26CF7C861640AAD5CEB1218D60A10500CECC@egwbeex001.esko-graphics.com>
To: "Alex Porras" <alex.porras@dds.mediaocean.com>
Cc: <xmlschema-dev@w3.org>

In Scenario 1, you are allowed to make a single choice, either choose an
unbounded number of foo (but minimum 1 - the default minOccurs) or
alternatively choose an unbounded number of bar
Your interpretation is incorrect: the maxOccurs attribute does not
override the other one.
Possible sequences: f fff ffffff b bb bbbb
Not possible: fb, empty sequence, fffbbbff

In scenario 2, you are allowed to make an unbounded number of choices
(but minimum 1), each one either choosing the unbounded number of foo or
an unbounded number of bar.
Possible sequences: f fff ffffff b bb bbbb fb fffbbbbbbffb
Not possible: empty sequence

Scenario 3: 
<xs:choice maxOccurs="unbounded">
     <xs:element name="foo" type="xs:string" maxOccurs="1"/>
     <xs:element name="bar" type="xs:string" maxOccurs="1"/> 
</xs:choice>

You are allowed to make an unbounded number of choices (but minimum 1),
each one either choosing a single foo or a single bar.
The possible sequences are exactly the same as in scenario 2.

Scenario 4: 
<xs:choice maxOccurs="1">
     <xs:element name="foo" type="xs:string" maxOccurs="1"/>
     <xs:element name="bar" type="xs:string" maxOccurs="1"/> 
</xs:choice>
You are allowed to make a single choice, either choose a single foo or
alternatively choose a single bar
Possible sequences: f b 
Not possible: empty sequence ff bb fb

> In other words, how is scenario 2 different 
> than just having the elements on their own, without the 
> choice element?
I don't understand what you mean with 'on their own'.

Kind regards,

Andy Den Tandt

============================================
Andy Den Tandt
Product Manager
Enfocus, an EskoArtwork company
 
Tel: +32 9 216 98 27 - Fax: +32 9 216 98 54 EskoArtwork NV,
Kortrijksesteenweg 1095
BE-9051 Gent, Belgium
andydt@enfocus.com - www.enfocus.com
 

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Alex Porras
> Sent: Friday, October 31, 2008 3:29 PM
> To: xmlschema-dev@w3.org
> Subject: RE: inquiry into the <choice> element behavior
> 
> 
> Michael,
> 
> Thanks for your prompt response.  If you could be so kind to 
> help me understand the result when the maxOccurs exists at 
> both the choice and the nested elements, it would be greatly 
> appreciated.
> 
> Scenario 1:
> 
> <xs:choice maxOccurs="1">
>      <xs:element name="foo" type="xs:string" maxOccurs="unbounded"/>
>      <xs:element name="bar" type="xs:string" 
> maxOccurs="unbounded"/> </xs:choice>
> 
> Is it correct to interpret this as: only one of either "foo" or "bar" 
> allowed, with the implication that the "maxOccurs" attributes 
> in the nested elements are essentially limited to 1 by the 
> parent's "maxOccurrs" attribute?
> 
> Scenario 2:
> 
> <xs:choice maxOccurs="unbounded">
>      <xs:element name="foo" type="xs:string" maxOccurs="unbounded"/>
>      <xs:element name="bar" type="xs:string" 
> maxOccurs="unbounded"/> </xs:choice>
> 
> This would allow any number of both "foo" *and* "bar" 
> elements, right? 
> Does this contradict the purpose of the choice element to 
> begin with, or am I just misunderstanding the function of the 
> choice element?  In other words, how is scenario 2 different 
> than just having the elements on their own, without the 
> choice element?
> 
> Thanks,
> 
> Alex
> 
> 
> 
Received on Monday, 3 November 2008 09:32:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:15:09 GMT