axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Sosnoski (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Commented: (AXIS-2155) Cannot distinguish "element not present" and "element present and nil"
Date Sun, 14 Aug 2005 22:05:54 GMT
    [ 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


Mime
View raw message