----- Original Message -----
From: "Joe Fialli" <joseph.fialli_at_sun.com>
To: <JAXB-INTEREST_at_JAVA.SUN.COM>
Sent: Tuesday, December 03, 2002 3:43 PM
Subject: Re: Nillable elements
> Marek Malowidzki wrote:
> > Hi all,
> >
> > Is there any way to distinguish nilled element (with xsi:nil="true") from a
> > missing one (i.e., not present in an instance document)?
>
> This capability was deliberated in the JAXB expert group and the decision
> was made to not expose this in the Java API. From a JavaBean property
> perspective, there is nothing to really gain for a Java programmer
> to have to distinguish between the XML concepts of absent from
> document and xsi:nil="true". The marshal method is capable of
> managing when an "xsi:nil" attribute is necessary to produce
> a valid element.
In the current beta version, the code generated by the compiler is quite funny.
Take a look:
public String getDefaultValue() {
return _DefaultValue;
}
public void setDefaultValue(String value) {
_DefaultValue = value;
}
public boolean isSetDefaultValue() {
return (_DefaultValue!= null);
}
public void unsetDefaultValue() {
_DefaultValue = null;
}
and then the marshaling method:
public void serializeElements(com.sun.xml.bind.serializer.XMLSerializer
context)
throws org.xml.sax.SAXException
{
// skipped some code here
if (_DefaultValue!= null) {
context.startElement("", "default-value");
if (!(_DefaultValue instanceof String)) {
if (_DefaultValue == null) {
context.startAttribute("
http://www.w3.org/2001/XMLSchema-instance", "nil");
context.text("true");
context.endAttribute();
} else {
throw new org.xml.sax.SAXException("type mismatch error");
}
}
// etc.
}
So, it is equivalent when the element is missing and when it is nilled. The
marshaling method is funny because it first checks
if (_DefaultValue!= null) {
and then, within this if{} block:
if (_DefaultValue == null) {
> The goal of JAXB was to provide a more natural and easy to use
> means to access XML content. Propogating XML concepts such
> as this into the Java access API did not seem to add as
> much functionality as it did additional complexity.
Well, sometimes it could be useful. In my particular case, I need to provide a
way for an instance document to specify a default value or enforce that no
default value is available. The default value may be also taken from another
source (outside of XML). I can still use a kind of "__no__default__value__" to
mark such a case, but it is not as elegant as XML nilling.
So, I do not want to import XML-specific features into JAXB - rather, I would
like to distingiush the value of "null" from "no value at all". Well, what I can
understand from your explanations, there is no such possibility and I think I
will have to live with that ;-).
> JAXB does have a customization to test if a JAXB property is explicitly
> set or not. See Section 4.5.4 isSet Property Modifier for
> a description of the isSet method. This allows one to distinguish
> between a property with a value that was in the document vs.
> a schema specified default.
Yes, I am aware of that. However, there is no such possibility for attributes.
Unlike in the early access release.
Generally, I seem that the beta release has been significantly "trimmed" and it
has a lot of less features than the early release one. What I am missing most is
the possibility of adding custom interfaces. I can achieve something similar
with groups, but again there is nothing that allows to group attributes in
custom interfaces. My previous post on the list describes a hack (quite ugly)
that I had to do to force the beta release to generate a replacement for custom
interfaces. Are you going to do something with that (i.e., restore custom
interfaces)?
Anyway, thanks for your response.
Marek