RE: Optional elements that are nillable

Benjamin

This has been the subject of much discussion, but from practical testing we
have confirmed what many of us in the working group believed, that this
situation is ambiguous. In reality practical testing has revealed interoperability
issues around the use of nillable and xsi:nil in general, and it seems
likely we may remove such patterns from our "Basic" set - patterns know
to interoperate well with current state of the art implementations.

I'll formally track your mail as a "Last Call Comment" for the Basic
specification, and we will inform you of the Working Group's decision on 
this issue prior to progressing Basic patterns documentation towards
publication, later this quarter.

Paul

-----Original Message-----
From: public-xsd-databinding-request@w3.org on behalf of Reif, Benjamin
Sent: Wed 6/20/2007 7:54 PM
To: public-xsd-databinding@w3.org
Subject: Optional elements that are nillable
 
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 Tuesday, 3 July 2007 21:22:00 UTC