Issue 177: missing elements same as nils?

The ETF was tasked with coming up with a recommendation for issue 177
[1] which points out an apparent conflict in the SOAP 1.2 spec part 2.
This mail is an attempt on my behalf to capture the discussion that has
happened within the ETF and to propose a word change to remove the
conflict. I apologize if I have failed to capture all aspects of the
discussion or deviate from the understanding of the other parties in the
ETF.

The respective pieces of text are:

(section 3.1, rule #8) [3] "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:nil
with value '1 or true' [...]"

and

(section 3.6 [4]) "An omitted accessor element implies either a default
value or that no value is known. The specifics depend on the accessor,
method, and its context. For example, an omitted accessor typically
implies a Null value for polymorphic accessors (with the exact meaning
of Null accessor-dependent). Likewise, an omitted Boolean accessor
typically implies either a False value or that no value is known, and an
omitted numeric accessor typically implies either that the value is zero
or that no value is known."

The issue is stated as follows: The first statement seems to indicate
that there is a difference between NULL and a default value whereas the
latter does not.

Analysis and Proposal:

While there is and has been a lot of discussion about what NULL means,
the SOAP encoding does not need to answer questions of meaning. Rather,
it merely needs to provide rules for a transformation between the data
model described in part 2, section 2 and some encoding--in this case the
particular encoding that we provide in part 2, section 3.

Default values are not part of our data model. They are at a higher
semantic level. It is sufficient for us to describe an encoding
serialization that permits omitted values and null values. We can leave
it to higher levels to decide whether and under what circumstances an
omitted or null value is a signal that the reader should infer a default
value or other out-of-band behavior. We can, therefore, either remove
section 3.6 which is already very loose or downgrade it to a note rather
than having it as an independent section.

Regarding nulls and omitted values, some languages and data models make
a distinction between these and others do not. As indicated in part 2,
section 2, we need to accommodate both. That means that we need to
permit that omission may result in a serialized form that is distinct
from NULL, or that it may not.

The proposal for solving this issue is as follows:

1) Simplify section 3.1 rule #8 to say: "A NULL value MAY be represented
by omission of the accessor element or by an accessor element containing
the attribute xsi:nil with value True.

2) Remove section 3.6 or downgrade it to a note in section 2 talking
about application-specific interpretation of instances of the data
model.

Thank you,

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x177
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0057.html
[3] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#encrules
[4] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#N750

Received on Wednesday, 6 February 2002 01:13:47 UTC