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

Dennis Sosnoski commented on AXIS-2155:
---------------------------------------

By general usage convention, xsi:nil is used in web services for the purpose of 
indicating null or missing items. Leaving out a minOccurs='0' element serves 
largely the same purpose and is generally preferred, except in the case of 
repeated elements - there xsi:nil is needed in order to indicate that a 
particular item within an ordered sequence of items is null or missing. Trying 
to distinguish between xsi:nil and a missing element is adding needless 
complexity and making assumptions about how frameworks are going to interpret 
schema definitions, so I can't see how this qualifies as a bug.

If you need to distinguish between the cases of an unspecified value and null 
value, I suggest you create a schema representation that serves this purpose. 
For example, you could use an optional attribute for the unspecified case with 
a schema definition like:

<element name="databaseValue" nillable="true">
 <complexType>
  <sequence>
    <!-- any type of child content here -->
   </sequence>
   <attribute name="unspecified" type="boolean" use="optional" default="false"/>
 </complexType>
</element>

Then you could have the separate cases in instance documents:

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

This would give you the cleanest XML representation for what you want. I don't 
know if Axis and other frameworks would process it correctly, though (in fact, 
I'm pretty sure Axis would not). Frameworks will probably assume that 
xsi:nil='true' means the element can be completely ignored, even though the 
schema specification says you can still use attributes in combination with 
xsi:nil='true'. For best interoperability you'd probably want to wrap this with 
an added element owning the "unspecified" attribute, then have that added 
element contain the (optional) value. You can always try the clean approach 
first, though, and then enter bug reports against the frameworks which 
(incorrectly) ignore the unspecified="true" attribute value.

> 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