Re: [xdi] Re: Proposal about null vs. undefined values

I am against introducing such a semantic distinction for the reasons I already mentioned.
When storing data, either it is there or it is not there.
I don't know of any data model that distinguishes between the three states null, not null, and undefined.

In general I find the approach of comparing XDI to programming languages (Java, _javascript_, Perl, ...) quite useless.

I also find the following sentence from the XDI TC minutes inapplicable since it only talks about one specific JSON implementation rather than the general concepts:
"Java’s null is not equivalent to JSON null but to JSON undefined"
http://json-lib.sourceforge.net/apidocs/jdk15/net/sf/json/JSONNull.html

I recognize that your cases 1. and 2. are somehow different, and it is tempting to assign different semantics to them. I think however that we should not introduce such different semantics in the XDI spec. One approach could be to remain silent about this, and leave it up to whoever uses XDI.

Markus

On Sun, Aug 18, 2013 at 6:58 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

[sorry - I hit the wrong key combination in Gmail and it accidentally sent the message before I was done. Ignore the last message and respond to this one.]

Per the minutes I just sent out, we did not reach a conclusion on the null vs. undefined values decision. In this message I will attempt to present a decision tree to try to close on this issue.

The first decision is: are we going to treat a null value and an undefined (or "unassigned") value as semantically distinct?

If YES, I believe the resolution of the issue is relatively simple because the use of value context nodes gives us a clean way to deal with all three cases:
If an attribute exists but has no value context node, it means the value is undefined.

If an attribute exists and has a value context node but no literal node, it means the value is null.
If an attribute exists and has a value context node and a literal node, it means the value is not null.

In this case, the only decision remaining (as best as I can tell) is how to serialize option #2. There are two choices:
Serialize it as a value context node that has no literal node.
Serialize it as a value context node with a literal node whose value is JSON null.
Of these two options, I prefer #2, because it means we can say that XDI can roundtrip all the JSON data types, i.e., if you $set an attribute with a value of JSON null, you will get back an attribute with a value of JSON null.

If the answer to the first question is NO, i.e., we do not want to treat a null value and an undefined value as semantically distinct, then we have a different issue, which is how we deal with the difference between #1 and #2 in the first list above.

Thoughts?

xdi message