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

[Joseph Boyle <planetwork@josephboyle.net>]

It's tempting to map JSON's value null to some special role in the XDI graph, but I think this opens the door to problems unless it's really an exact fit. Client programs could be using any semantics for JSON null, so any specific XDI semantics will differ from somebody's.

XDI values are JSON values, and XDI promises round-trippable storage of them. The straightforward way to do this is to explicitly represent it as a special value like JSON's values true and false. 

I believe the status quo is non-roundtrippable because the two cases of not assigning a value to an attribute, and assigning JSON null as the value of an attribute, produce the same result in the XDI graph, which becomes JSON null on retrieval. This is the issue my example raised. Markus, can you confirm whether current behavior is as I just described?

On Aug 17, 2013, at 9:58 PM, 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:

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?