- From: Reif, Benjamin <benjamin.reif@cgi.com>
- Date: Wed, 20 Jun 2007 14:54:41 -0400
- To: <public-xsd-databinding@w3.org>
- Message-ID: <ED4591B6B5F6F04DA979B8E93A8F5D72575306@PHX-MSG-02.cgiclients.com>
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 UTC