RE: Section 5 Item 9 of the SOAP spec

Thank you for your clear mail. I'm just back from vacation, catching up
on things, and am almost certainly missing some context, but here are my
thoughts, as you request, on the matter of having a distinction between
"null" and "void" in section SOAP section 5:

Standardizing the representation of "nulls" in section 5 is always going
to be a problem because section 5 describes mappings from a foreign type
model to XML syntax, and foreign type models may have inconsistent or
underspecified uses of "nulls."  

I believe that it leads to all sorts of confused thinking to try and
treat NULL as though it is a kind of data type.  We are better off
recognizing that NULL is like the English word "nothing", representing
not something but the absence of something, and used largely because the
rules of English grammar sometimes necessitate it, for example,
requiring verbs to have objects.  (e.g. If we go shopping but don't buy
anything, we must say "I bought nothing" rather than "I bought.")
Sometimes a rule of XML grammar will require an element to appear
despite empty content, and for that the xsi:nil attribute is provided,
but just as English does not require every sentence to enumerate all
facts that it does not say, neither should our use of XML.  

Regarding the issue in section 5, data representation in foreign type
models, in some cases, such as the effect of a SQL OUTER JOIN, nulls and
absence are equivalent. In many cases, the distinction between null and
void is only a matter of whether the absence of something was late-bound
or early bound. We should not encourage syntax to be different between
early and late bound representation of the same facts, else that gets in
the way of the flexibility and extensibility of XML and semi-structured
data generally.

You appear to have a good solution in the proposal to give the return
value of a function a namespace-qualified name, making it unambiguous
with any possible parameter name.

Given that, I don't find much merit in the argument that a further
distinction between "void" and "null" return "values" is warranted.  If
someone might "by accident" write their program so that it omits the
return value, they might by equal accident make any number of errors.  

XML long-ago took an approach that differs sharply from HTML.  Because
HTML is meant for human readers, HTML browsers are expected to be
adaptive in the face of bad data and present something approximate for
the human to figure out.  But XML, when it split from SGML, became meant
for machine-generation and processing primarily, and so has "Draconian
error handling" and other features that require the writer of the XML to
get it right.

Of the arguments that I present above, I think that the strongest
motivator is the need to keep data representation the same whether the
data is computed early or late-bound.

-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Thursday, August 23, 2001 5:05 AM
To: Frank DeRose
Cc: Andrew Layman; gdaniels@macromedia.com
Subject: Re: Section 5 Item 9 of the SOAP spec


Minor typo - I think it was Glen Daniels who mentioned you had a
preference.
8-)
-Dug

Doug Davis
dug@us.ibm.com



"Frank DeRose" <frankd@tibco.com>@w3.org on 08/22/2001 04:46:53 PM

Sent by:  xml-dist-app-request@w3.org


To:   "Andrew Layman" <andrewl@microsoft.com>, <xml-dist-app@w3.org>
cc:
Subject:  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 Thursday, 23 August 2001 15:03:23 UTC