Sam, I didn't see a test for a 'null' return value (or null parameter). Did I miss something ? Seems like an interesting test case for interoperability ?
So, perhaps the best way to insure reasonable interoperability for now is for the API to not return null, but throw an exception (that translates to a SOAP Fault) ? Or return a prespecified instance of the object signifying the 'failure' condition ... -john ----- Original Message ----- From: "Sam Ruby" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 04, 2002 8:56 AM Subject: Re: returning null object > Chris Malley wrote: > > > > See the SOAP 1.2 spec at http://www.w3.org/TR/2001/WD-soap12-20010709. > > As stated towards the end of Section 5.1: > > > > "9. A NULL value or a default value MAY be represented by omission > > of the accessor element. A NULL value MAY also be indicated by > > an accessor element containing the attribute xsi:null with value > > '1' or possibly other application-dependent attributes and values." > > > > So the treatment of 'null' is left up to the implementation, > > since "MAY" indicates that these are only suggestions. > > I believe that Apache SOAP 2.2 takes the 'xsi:null' approach. > > You are correct. > > One ramification of this is that there is no way using the RPCProvider to > get Apache SOAP 2.2 to omit the return element. This may cause > interoperability problems with other web services which do not expect to > see a response. > > The RPCProvider in Apache xml-axis distinguishes between methods who are > declared to return void, and methods who happen to return null in this one > instance. > > If anyone listening is interested in interoperability issues, you might > want to take a look at > http://www.apache.org/~rubys/ApacheClientInterop.html and some of the web > pages which it is linked to. It has been an interesting journey. I have > found that sending only valid SOAP messages is not sufficient. Nor is > being able to consume every message that you can produce. The harder > problem is being able to produce messages to a required specification, and > to consume every possible response. > > It appears that this journey is one that will take a while - exploring all > of the edge cases and finding new nooks and cranies. > > - Sam Ruby > >
