 |
 |
 |
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@d...>
To: <xmlschema-dev@w...>
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
>
>
>
|
 | 

|  |
These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.
|  |
| |
 |
 |
 |