axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <>
Subject RE: Issue xsi:nil="true" sent even if send xsi is off (UNDO FIX....MORE)
Date Mon, 31 Dec 2001 19:21:07 GMT
After looking at the code some more, it seems to me that the intention of
the PROP_SEND_XSI property is to turn off the xsi:type for the engine
(not to turn off xsi:nil or other xsi attributes).  Here is the declaration
of PROP_SEND_XSI in AxisEngine.

    public static final String PROP_SEND_XSI = "sendXsiTypes";

The name of the property should have been PROP_SEND_XSI_TYPES...

Therefore I am going undo my last fix.  Thanks Sam.

Should we have a PROP_NIL attribute (on both the Engine and the Call)?

It could have three flavors:
1) (default)  Use the xsi:nil="true" attribute to serialize null objects.
2) Don't serialize null objects.
3) Serialize null objects as empty elements.

Comments ?

Rich Scheuerle
XML & Web Services Development
512-838-5115  (IBM TL 678-5115)

                    Ruby/Raleigh/I       To:                 
                    BM@IBMUS             cc:                                             
                                         Subject:     RE: Issue xsi:nil="true" sent even if
send xsi is    
                    12/31/2001            off (FIXED)                                    
                    10:37 AM                                                             
                    Please respond                                                       
                    to axis-dev                                                          

Rich Scheuerle Jr wrote:
> What should be the proper behavior under these circumstances?
> 1)  Don't serialize the element at all?
>      -or-
> 2) Serialize an empty element?

There is signficant difference between <symbol xsi:nil="true"/> and
<symbol/>.  In Java terms, this is the difference between symbol=null and

The option to turn xsi off is not something required by the spec, it merely
is something that Glen felt was useful.  In other words, we can
collectively decide what this option means, or even do away with this
option entirely.  I don't feel strongly either way, I just don't
particularly care for this setting changing the semantics of what is

Not serializing the element at all is a valid approach.  The issue that
would need to be tackled with this approach is that rpc is currently done
via positional parameters...

For the moment, my recommendation is to undo this fix, and rename and/or
document this option more completely.

- Sam Ruby

View raw message