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

As Drummond pointed out, there are currently two ways of "not assigning a value to an attribute":

An attribute exists but has no value context node.
An attribute exists and has a value context node but no literal node.

Example of case 1 (in XDI DISPLAY format):

=markus/()/<+email>

Example of case 1 (in XDI/JSON format):
{
"=markus/()": [
"<+email>"
]
}

Example of case 2 (in XDI DISPLAY format):

=markus<+email>/()/&

Example of case 2 (in XDI/JSON format):
{
"=markus<+email>/()": [
"&"
]
}

Not that in both cases, the result on retrieval of the attribute (i.e. if you do a $get on =markus<+email>) will not contain a literal. Most importantly, the result will never be anything of this kind:
{
"=markus<+email>&/&": null
}

Not sure if I am answering your question. I'd say that with the current implementation, the JSON null value is non-roundtrippable, because the JSON null value cannot be stored in the graph. But the concept of "not having data at a certain address" is perfectly roundtrippable.

Also see attached screenshots to illustrate the three cases Drummond listed in his original e-mail. I have to admit, the fact that we have two different ways of "not assigning a value to an attribute" also bugs me a bit.

Markus

On Sun, Aug 18, 2013 at 6:19 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:

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