Re: Issue xsi:nil="true" sent even if send xsi is off (FIXED)

[Glen Daniels <gd...@macromedia.com>]

Hi Sam, Rich!

+1 to removing the "fix"; thanks, Rich.  A couple of comments:

The community in general seems to be leaning towards supporting the "missing
element == null value" as at least a valid option, and Axis should probably
gear up to deal with that at some point.  This might mean getting into the
business of using the debug data in compiled bytecode to extract parameter
names....

The point of putting the option of sending or not sending the xsi:type
attribute (which is indeed orthogonal to the xsi:nil attribute) was to
support the optionality allowed in the SOAP spec for this.  It's more
efficient not to send it, both in terms of code and bandwidth, and I also
wanted to make sure Axis could be used to test its own ability to get type
information for encoded values from explicit (call.setReturnType()) or
implicit (reflection) metadata.  I think it's definitely a good option to
leave in.

--Glen

----- Original Message -----
From: "Sam Ruby" <ru...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Monday, December 31, 2001 11:37 AM
Subject: RE: Issue xsi:nil="true" sent even if send xsi is off (FIXED)


> 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
> symbol="".
>
> 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
> transmitted.
>
> 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
>