Andreas,
See my thoughts inline below as far as expert group thoughts on this
subject.
Andreas.Ebbert_at_nokia.com wrote:
> Hi,
>
> I asked this question also in todays BOF at JavaOne, but since I was
> in the back of the audience, my questions was probably not understood,
> or I have not understood the answer properly.
>
> Anyways, this is the issue, what is the approach, how JAXB will
> (does?) handle elements in XML documents, that the XML Schema defines
> as minOccurs=0 and nillable=true. Examples of these schemas can be
> found in the OSS through Java Initiative:
>
> http://java.sun.com/products/oss/xml/xml_schema_table.html
>
> For an example of a complexType, which contains elements, which are
> optional and nillable, look in the Service Activation Schema
> (http://java.sun.com/products/oss/xml/ServiceActivation/XmlServiceActivationSchema.xsd)
> for the complex type 'OrderValue'.
>
> The business reason behind this is, that we have the use case of
> possibly transferring massives amount of data to the client. So the
> client can request which elements it would like to be returned, while
> these elements then still can be null.
>
> My question is, if there is
> * any understanding of this issue in the JAXB EG
The expert group was aware of this issue and many other related issues.
This high level non-goal covers your issue.
From JAXB 1.0 specification 1.3 Non-Goals:
- Preserving equivalence of XML document when round tripping
from XML document to Java representation and back to XML
document again.
While the JAXB specification does not require the preservation of the
XML information set, it does not forbid the preservation of it.
End extraction.
*******************
The intentiion being that JAXB 1.0 did not want to require all JAXB
implementations to have to preserve the XML infoset (and have to expose
access to it). Or the complexities of understanding it.
XML has many scenarios where multiple lexical values exist for one
canonical value.
(Example for boolean "true" or 1, "false" or 0. JAXB 1.0 did not want
to have
to differentiate between these representations and remember them for
roundtripping sake.
Your scenerio of minOccurs="0" and nillable="true at same time.
In order to allow for the most efficient implementations
as possible, the JAXB 1.0 specification did not want to require binding
to have to preserve
these lexical differences, we preferred to allow for equivent value.
The JAXB 1.0 specification definitely handles the case when
minOccurs="1" and an element is nillable.
For that case, either setting the property to "null" or having the
optional "unset"/"isSet" property generated
allows the preservation of nil in the output. However, in an effort to
not expose the complexities of XML Schema
in the schema-derived Java binding, the expert group choose to not have
explicit setNil<Property>() other
than on an element.
JAXB 2.0 effort has on its agenda to research improved roundtripping
over JAXB 1.0. For your
particular issue, I beleive that the early draft of JAXB 2.0 has the
building blocks that could be used to
address your reported issue.
Specifically, JAXB 2.0 introduced javax.xml.bind.XmlElement<T> has a
isNil() and setNil() property.
Also Section 5.5 "Element property" provides the API from Java to be able
to designate that an Element be considered nil. Element property was added
to JAXB 2.0 to support element substitution group. It could just as
easily be used
to support your use case of an element with minOccurs="0" and
nillable="true".
The JAXB 2.0 early draft specification and Javadoc of
javax.xml.bind.XmlElement<T> are available for review
at
http://jcp.org/aboutJava/communityprocess/edr/jsr222/. The expert
group welcomes your feedback on this
early draft release.
-Joe Fialli, Sun Microsystems
>
> * any idea how to make this information available in the Java
> Interface (we have the javax.oss.AttributeAccess interface defined in
> the OSS Common API (JSR 144) defined for that purpose)
> * any guess, how difficult it would be to enhance the JAXB RI to
> generate code that matches this requirement
>
> Thanks for your attention!
>
> Andreas Ebbert
> Software Design Engineer - Nokia Networks OSS
> phone: +49-211-94123928, fax: +49-211-94123838
> Heltorfer Straße 1, 40472 Düsseldorf, Germany
>
> ------------------------------------------------------------------------
> This message is confidential. If you have received this message in
> error, please delete it from your system. You should not copy it for
> any purpose, or disclose its contents to any other person. Internet
> communications are not secure and therefore Nokia GmbH does not accept
> legal responsibility for the contents of this message as it has been
> transmitted over a public network. Thank you.
>
> Nokia GmbH, Nokia Networks is a German Company. Further information
> about the Company is available from its principal offices at
> Heltorferstrasse 1, D-40472, Düsseldorf, Germany and from the website
> at http://www.nokia.com/
> ------------------------------------------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net