On 15 September 2011 19:06, John G. Lussmyer <Cougar_at_casadelgato.com> wrote:
> Sorry, I take that back. It's basically a useless change.
> It seems to require that I work with JAXBElements, rather than objects of
> the types I defined.
>
The fundamental problem is that an XML element needs a tag in addition to
its contents.
> Marshall won't marshall an Options object.
>
How would you propose or expect to define, for a marshaller, the tag string
for the element representing you Options object?
> And I think that Unmarshall will return a JAXBElement rather than an
> Options.
>
Same issue here - the tag string has to be kept somewhere, and this can't be
inside the Options object.
Notice that the ObjectFactory methods take care of JAXBElement compositions.
And getting the actual object from a JAXBElement is a simple method call.
-W
>
>
> On 9/15/2011 9:19 AM, John G. Lussmyer wrote:
>
> Thanks, that does seem to work. I thought I had tried that, and gotten an
> extra level of java name in there.
>
> Due to other problems with our systems right now, i can't actually run
> anything.
>
> Do the Element names actually show up anywhere in the XML?
>
> On 9/15/2011 2:43 AM, Wolfgang Laun wrote:
>
>
> <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".
>>
>>
>
>
> --
> --
> John G. Lussmyer mailto:Cougar_at_CasaDelGato.Com <Cougar_at_CasaDelGato.Com>
> Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com
>
>
>
> --
> --
> John G. Lussmyer mailto:Cougar_at_CasaDelGato.Com <Cougar_at_CasaDelGato.Com>
> Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com
>
>