Section 5 Item 9 of the SOAP spec

Andrew,

A proposal [1] was recently submitted to the XMLP WG to resolve issues #16
and #113. The proposal is to introduce a "result" element in the (to be
defined) rpc namespace to represent the return value of an RPC call. We can
call this element rpc:result.

According to the proposal, the response element (the struct that contains
the return value and all the [out] parameters) for an RPC, would be
constructed according to the following rules:

if the return type of the procedure is nonvoid
  if the return value of the procedure is nonnull
    rpc:result is present with nonempty content
  else // the return value of the procedure is null
    Alternative 1: rpc:result is present, with empty content, and with the
xsi:nill attribute
    Alternative 2: rpc:result is omitted
else // the return type of the procedure is void
  rpc:result is omitted

The reason for allowing both Alternative 1 and Alternative 2 is Section 5,
Item 9 of the SOAP spec, which states:

"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."

However, if we allow the response element (struct) for a procedure with a
nonvoid return type to omit the rpc:result element if the return value is
null, then, it's impossible to determine whether such an omission is an
error (the replying SOAP processor had a non-null return value, but just
forgot to add the rpc:result element) or not (the return value was, in fact,
null). (Actually, I guess the same argument applies to the omission of any
accessor.)

Consequently, several people in the WG have expressed a strong preference
for requiring that the rpc:result element always be present in a response
element for a procedure with a nonvoid return type; when the return value is
null, this would be indicated by the presence of the xsi:nill attribute. In
other words, we would allow Alternative 1 and forbid Alternative 2. However,
as already pointed out, adopting such a requirement would mean tossing
Section 5, Item 9.

Doug Davis mentioned that you had a strong preference for keeping Section 5,
Item 9 unchanged and that you had possibly posted arguments to the
soapbuilders mailing list defending this position. Can you please forward
those arguments to the XMLP WG public mailing list? In other words, why
should we allow null values to be represented by omission of the accessor
instead of forcing the accessor to be present with the xsi:nill attribute?

Thanks.

Frank DeRose
TIBCO Software Inc.
3165 Porter Dr
Palo Alto, CA 94303
650-846-5570 (vox)
650-846-1267 (fax)
frankd@tibco.com
www.tibco.com

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0170.html

Received on Wednesday, 22 August 2001 16:48:12 UTC