users@jaxb.java.net

Re: UnmarshallException "Unexpected element {}:xxx"

From: Irv Thomae <ithomae_at_ists.dartmouth.edu>
Date: Wed, 04 Dec 2002 10:53:41 -0500

Joe Fialli wrote:

>> .....
>>
>> <router name="63.209.255.229 (ATT-SD)">
>> <adds>6</adds>
>> <drops>1</drops>
>> </router>
>
>
> This data file is not valid in terms of the schema below.
> "adds" and "drops" should be attributes of element <router>,
> not children elements.
>
> A valid router element is the following.
> <router name="..." adds="6" drops="1"/>
>
>>
>> <as number="701">
>> <routearounds>26</routearounds>
>> <disconnects>2</disconnects>
>> </as>
>
>
> Same mistake here.
>
> <as number="" routearounds="..." disconnects="..."/>
>
>
> -Joe Fialli, Sun Microsystems
>
    Thanks, but I need to deal with the data files as they already
exist. Is there a way to rewrite the schema so that it correctly
describes their actual structure? I did first try using "element"
instead of "attribute"; but was confused by the fact that (for example)
in the generated file "RouterReport.java" , interface RouterReport
defines a "getContent()" method, which returns type java.util.List.
For each element there is a distinct interface type with getValue() and
setValue() methods, but since the getContent() situation is not
illustrated by the PurchaseOrderType example, it is not at all obvious
how to achieve (for example) getAdds() functionality starting from
RouterReport.getContent() . Must "instanceOf" tests be applied to
every item retrieved from that List? That is significantly less
elegant than the straightforward method-set in the Examples, for ex.
interface ItemType, or interface PurchaseOrderType.

     If seemingly small departures from the model schema are likely to
produce major changes in the form of the generated interfaces and
classes, the Users' Guide should at least warn the unwary user, and
provide some guidance in how to proceed.

     Newcomers to both XML schema and JAXB like myself may discover few
if any bugs in your beta code, but perhaps we can be helpful in
beta-testing the documentation. In that spirit, I believe that the
errrors you've pointed out arose from not fully understanding the
distinction between "attribute" and "element". The Users' Guide is
already very good, but this is a topic that needs to be explained more
clearly. I know that only elements can contain other elements, but at
a terminal node of the tree, it is not clear (to me at least)
when/why/how to choose between "element" and "attribute".

    Another Users' Guide question: The examples all use a package name
"primer.po". Is that a subtle hint that "dotted" package names are
preferable for some reason, or is it simply an artifact of the directory
structure on the system(s) used to develop and test those examples?

Thank you,
   Irv Thomae
   ISTS/Dartmouth College

>
> ....
>
>> ====================================================
>>
>>
>> <xsd:complexType name="routerReport">
>> <xsd:attribute name="name" type="xsd:string" use="required"/>
>> <xsd:attribute name="adds" type="xsd:integer"/>
>> <xsd:attribute name="drops" type="xsd:integer"/>
>> </xsd:complexType>
>