OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I am concerned about treating these differently, as it allows for an existence test of an attribute (present, with an undefined value). If an attribute exists, but its' value is concealed by policy, then the attribute itself should either be hidden entirely, or always carry the same value (null?) irrespective of the presence of one or more values.

the proposal below would allow a client to know that there is a value for a given attribute, i think.

=peterd

On Aug 18, 2013, at 24: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:
  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?




Peter Davis: Neustar, Inc.
Distinguished Engineer, Neustar Labs
45980 Center Oak Plaza Sterling, VA 20166

The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]