[XMLSCHEMA-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: inquiry into the <choice> element behavior

From: Pete Cordell <petexmldev@codalogic.com>
Date: Thu, 30 Oct 2008 22:13:44 -0000
Message-ID: <9548A749C3AF4FBEA6B9FFEA08941D66@Codalogic>
To: <xmlschema-dev@w3.org>, <Jeffrey.Kramer@dds.net>
Re: inquiry into the <choice> element behavior

Original Message From: Jeffrey.Kramer

> We were hoping to get a definitive answer on how the <choice> element is
> supposed to behave.
>
> We observed kind of a counter intuitive result of choice in a test.  i.e.,
> we'd think it was going to be mutually exclusive across it's elements,
> although when we provided >1 types it actually spit out both ( see below )

The result you are getting for the XSD segment you show is correct.  You've 
effectively allowing multiple instances of the choice, where each choice is 
independent, much as if you had:

    ChoiceClass[]  myChoices;

If you wanted one option or the other, but wanted to allow multiple 
instances of which ever one was chosen, you would do something like the 
following XSD segment:

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

HTH,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://www.codalogic.com/lmx/ for more info

----- Original Message ----- 
From: <Jeffrey.Kramer@dds.net>
To: <xmlschema-dev@w3.org>
Sent: Thursday, October 30, 2008 6:45 PM
Subject: inquiry into the <choice> element behavior


> We were hoping to get a definitive answer on how the <choice> element is
> supposed to behave.
>
> We observed kind of a counter intuitive result of choice in a test.  i.e.,
> we'd think it was going to be mutually exclusive across it's elements,
> although when we provided >1 types it actually spit out both ( see below )
>
> i.e.,
>
> providing
> ....
>        <foo>1</foo>
>        <foo>2</foo>
>        <bar>3</bar>
> ...
> to
> ..
>         <xs:choice  maxOccurs="unbounded">
>            <xs:element name="foo" type="xs:string" />
>            <xs:element name="bar" type="xs:string" />
>       </xs:choice>
>
> yields:
>
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #startElement:
> foo
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #characters: 1
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #endElement: foo
>
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #startElement:
> foo
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #characters: 2
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #endElement: foo
>
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #startElement:
> bar
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #characters: 3
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #endElement: bar
>
>
> We were kind of thinking the choice would somehow be limited to only one
> of nested elements.  Perhaps we're misusing the maxOccurs?   Any insights
> greatly appreciated.  Thanks in advance.
>
> - Jeff
>
>
> 
Received on Thursday, 30 October 2008 22:14:33 GMT

Subscribe to the Stylus Scoop newsletter for helpful XML tips and tutorials.
Email
First Name
Last Name
Company

Download Stylus Studio 6 XML Enterprise Edition

Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.