Re: Issue 177: missing elements same as nils?

 Henrik,
 I think the proposal as you stated it below effectively states 
that an omitted member is a NULL, am I right?
 Why I think so: in our data model there are concrete values and 
NULLs. A concrete value is serialized as the value per other 
rules. A NULL then may be serialized with xsi:nil or as omission. 
There is nothing else that can be serialized with xsi:nil or as 
omission - therefore an omission is a NULL.
 Btw, if it is indeed so, I like this proposal very much because 
NULLs can be taken for default values by the application - out of 
scope of SOAP Encoding.
 Regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 5 Feb 2002, Henrik Frystyk Nielsen wrote:

 > 
 > 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 08:05:44 UTC