W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > June 2007

Optional elements that are nillable

From: Reif, Benjamin <benjamin.reif@cgi.com>
Date: Wed, 20 Jun 2007 14:54:41 -0400
Message-ID: <ED4591B6B5F6F04DA979B8E93A8F5D72575306@PHX-MSG-02.cgiclients.com>
To: <public-xsd-databinding@w3.org>
I had a question regarding the Basic XML Schema Patterns for Databinding
specification, more specifically, section 2.7.12
NillableOptionalElement. The current specification doesn't make a
distinction between, or address how to handle, elements that can be both
nillable and optional. When this specification is used in the context of
Web Services this becomes very problematic. There is no clear guidance
on what should be expected in a SOAP message if the WSDL defines that an
element is both optional (minOccurs="0") and can have a null value
(nillable="true"). 
 
For example, what should be expected in a SOAP message if a Web Services
client does not set any value for certain fields, but then explicitly
sets a null value for other fields? Many tools treat this as the same
thing (and don't send any data in the SOAP message), when in fact they
are very different. I would expect that if the WSDL says that an element
has minOccurs="0" and nillable="true" then the following should be
contained in the SOAP message:

*	If the field was never set by the client code then nothing
should be sent for that field in the SOAP message. 
*	If a value was explicitly set by the client code (even a null
value, since null is a value) then the element would be sent in the SOAP
message.

I have seen a few tools that handle this case in the way that I've
described above, but I think this is a big issue for many applications,
and there doesn't seem to be a standard way for venders to handle this
situation. 
 
I found a thread with some ideas on how this issue could be addressed (
http://www.w3.org/2002/ws/databinding/issues/7/
<http://www.w3.org/2002/ws/databinding/issues/7/>  ) in the way that
I've mentioned above. One approach handled it by generating code with an
internal boolean member variable to indicate if the field had been set;
and then in the field's setter method, setting that boolean to true
(even if the passed in value was null). This would allow serializers to
check the boolean and then they would know whether or not to include the
field, even if the value is null and the field was optional. 
 
Can anyone tell me if any decisions have been made regarding this, and
if it's likely that this behavior will be clearly stated in the next
version of the specification?

Thank you, 

Ben Reif

CGI Technologies and Solutions
Received on Thursday, 21 June 2007 10:52:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:20:37 GMT