[ 
http://issues.apache.org/jira/browse/AXIS-2155?page=comments#action_12318846 ] 

Peter Wisnovsky commented on AXIS-2155:
---------------------------------------

Hmm...I must defer to your knowledge of the consensus among the JAXRPC 
community regarding the treatment of minOccurs=0 and nillable=false. The JAXRPC 
spec seems to treat these, as you say, interchangeably. The XML Schema 
specification says only that xsi:nil=true connotes that the element should be 
accepted as valid but has no content, rather than the semantic -- as I inferred 
from the name "nil" -- that the element is present and the SQL notion of null 
applies, e.g. that it has a value of "no value".

Not having a formal way to express this semantic interoperably in the 
frameworks seems unfortunate. Our use case, which requires us to distinguish 
"not present in the request or response message" from "present with the value 
of 'no value'" would seem to map nicely into the "does not occur" and "nil" 
respectively. But this is not the forum, I suppose, to debate the design of XML 
Schema. 

FWIW, .NET's treatment of this seems different, cf.

"[For minOccurs = 0 the XML binding generator] Xsd.exe generates a public 
field. No XML-related attribute is applied, so the default XmlElementAttribute 
is used. In addition, Xsd.exe generates a public field of type bool whose name 
is the element field's name with Specified appended. For example, if the 
element field's name is startDate, the bool field's name becomes 
startDateSpecified. When serializing an object to XML, the XmlSerializer class 
checks the value of the bool field to determine whether to write the element. 
The bool field appears with a System.Xml.Serialization.XmlIgnoreAttribute to 
prevent it from being serialized by XmlSerializer."

Your suggestion is more or less what we have been trying, a specialized 
attribute in the schema. However we need to get Axis to send a message of the 
form 

<databaseValue xsi:nil="true" unspecified="true"/> 

either to the server from our Axis-based client lib or from the (Axis-based) 
server back to the .NET or Java client. I don't believe, even if the Axis 
deserializer can process this message inbound, that there is any way to cause 
this message to be emitted. Am I wrong?

Thanks for your help,

> Cannot distinguish "element not present" and "element present and nil"
> ----------------------------------------------------------------------
>
>          Key: AXIS-2155
>          URL: http://issues.apache.org/jira/browse/AXIS-2155
>      Project: Apache Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2.1
>  Environment: Windows XP
>     Reporter: Peter Wisnovsky
>     Priority: Critical
>  Attachments: simple_axis.zip
>
> I have a web service where I need to distinguish between "a value was not 
> sent" and "a value was sent and is nil", both to and from the server. If I 
> have an element of a complex type with a subelement where nillable="true" and 
> minOccurs="0" AXIS generates the attribute of the Java class, but there seems 
> to be no way to indicate for
> <xs:complexType name="ResourceType">
> <xs:complexContent>
> <xs:extension base="pvOperational:PersonType">
> <xs:sequence>
> ..
> <xs:element name="employerRef" type="pvOperational:AgencyReferenceType" 
> minOccurs="0" nillable="true"/>
> that I want no employerRef or a nil employerRef, e.g.
> <resource>
> <employerRef xsi:nil="true"/>
> </resource>
> versus
> <resource/>
> In either case all I see in the proxy is an attribute employerRef that might 
> or might not be null.
> Is this supported? JaxRPC is admittedly unclear on the point as the only 
> issue it discusses is the use of Java holder classes for primitives for 
> either minOccurs=0 OR nillable=true and does not discuss minOccurs=0 AND 
> nillable=true, but it seems pretty fundamental if you are dealing with 
> database-based services to have null indicators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to