Re: Proposal about null vs. undefined values

[Drummond Reed <drummond.reed@xdi.org>]

[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:

1. If an attribute exists but has no value context node, it means the value is undefined.
   
2. If an attribute exists and has a value context node but no literal node, it means the value is null.
   
3. 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:

1. Serialize it as a value context node that has no literal node.
2. 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?