<xs:element name="options" type="Options"/>
<xs:element name="option" type="Option"/>
<xs:complexType name="Options">
<xs:sequence>
<xs:element name="Option" type="Option"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="Option">
<xs:sequence>
<xs:element name="OptionId" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
It helps to define types and use them in element definitions (rather than
inline types). For clarity, I have changed element names to lower case, but
you can revert this, of course.
There is no problem with having two "top level" elements, and one (or both)
can be an element somewhere in the other.
Look at the generated ObjectFactory to see how createOption(s) is overloaded
so that you can construct top level elements as well as subordinate
elements. Also note where the XML element names are defined for top levels
and for subordinates.
-W
On 15 September 2011 00:46, John G. Lussmyer <Cougar_at_casadelgato.com> wrote:
> On 9/14/2011 11:04 AM, Wolfgang Laun wrote:
>
>> This is too abstract for me - please provide something tangible.
>>
>> Generally speaking, it's possible to have a complexType that's both a
>> component (list element or scalar) of another object and a solitary document
>> type.
>>
>
> Okay, here's a trimmed down example:
>
> <xs:element name="Options">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Option" type="Option" minOccurs="0" maxOccurs="unbounded"
> />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> <xs:complexType name="Option">
> <xs:sequence>
> <xs:element name="OptionId" type="OptionIdentifier" minOccurs="1"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
>
> I have some API's that take/return an "Options" and some that take/return a
> "Option".
> I can't make "Option" an xs:element, since that means it can't be used as a
> type in "Options".
>
>