XDI TC Agenda

Following is the agenda for the unofficial telecon of the XDI TC at:

Date: Friday, 23 August 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Markus Sabadello

Phil Windley

Les Chasen

Animesh Chowdhury

Drummond Reed

Joseph Boyle

GUESTS

Steve Greenberg

NEWS & UPDATES

XDI2 Report: Support for JSON Arrays and Objects

Per our discussion on last week’s call, Markus demonstrated what he implemented this past week in the XDI2 code base: support for roundtripping (storing and retrieving) of JSON arrays and objects as XDI literal values. This is all now supported in the XDI2 Local Messenger utility:

http://xdi2.projectdanube.org/XDILocalMessenger

PRESENTATIONS/DISCUSSIONS

Proposed Resolution of XRI Acronym Issue

Drummond reported that he talked to our TC Administrator, Chet Ensign, who clarified that there is no way to change the formal name of the TC without starting a completely new TC (even rechartering will not do it). Since no one wants to go through all the overhead of starting a completely new TC, Chet suggested that we take the following approach:

First, determine that there is concensus for the XDI TC to accept the contribution of the XRI TC’s work.
Second, have the XRI TC vote to close the TC and contribute the work to the XDI TC.
Third, once the XRI TC is closed, OASIS would post a notice on the XRI TC’s home page pointing to the XDI TC as the new steward of the XRI work.
Lastly, the XDI TC could formally redefine the acronym XRI (Extensible Resource Identifier) to be an XDI address.

The result would be that we could reintroduce the acronym, if needed, to the XDI TC and the XDI 1.0 specifications, and we would not need to change the formal name of our TC.

There was unanimous concensus among the TC members on the call that this was the best resolution.

#DECISION: The XDI TC will accept the contribution of the XRI TC’s work if the XRI TC votes to close and contribute its work to the XDI TC.

Progress on Working Drafts

Joseph reported that he’s still working on the ABNF section of XDI Core.

Markus has not done anything further yet on the XDI Messaging Draft.

We agreed to the following milestones for the first Working Drafts of both XDI Core and XDI Messaging:

Working Draft 01 by Sept 13
Working Draft 01 by Oct 18

This way we should be ready for Internet Identity Workshop which starts Oct 22.

DECISION POINTS FOR THIS CALL

JSON Null Issue

We have had more discussion about this issue that started on last Friday’s call and continued on the email list. The last two messages were:

Markus included the following graph diagram in the first message above which illustrates the three different attribute value states that may be associated with an attribute instance or attribute singleton in the graph:

The top graph is state #1, where the attribute has no value context node. It corresponds to this XDI statement:

=markus<+email>

The second graph is state #2, where the attribute has a value context node but no literal node. It corresponds to this XDI statement:

=markus<+email>&

The third graph is state #3, where the attribute has a value context node and a literal node and a value. It corresponds to this XDI statement:

=markus<+email>&/&/”markus.sabadello@gmail.com”

Drummond thanked Markus for contributing the diagrams because they help make the choices for the TC very clear.

Joseph clarified that his most recent message to the email list on this subject asserts that the the following should be two independent issues:

Roundtripability of the JSON null value
Representation of an undefined value in the graph

Drummond also said that, as a non-programmer looking at the issue simply from a logic and consistency point-of-view, it does seem to be very attractive for the XDI data model and protocol to support explicit _expression_ of a JSON null value that is round-trippable like all the other JSON value types. For example:

=markus<+email>&/&/null

Drummond said that if we did this—allowed a JSON null value in state #3 where there is an explicit literal node—that would mean the TC has exactly four options for state #1 (no value context node) and state #2 (no literal node):

Both state #1 and state #2 mean the value of the attribute is undefined.
Both state #1 and state #2 mean the value of the attribute is null.
State #1 means undefined and state #2 means null.
State #1 means null and state #2 means undefined.

Drummond proposed that we immediately eliminate options 3 and 4 because they are confusing and nearly impossible to remember.

Of the remaining two options, Drummond shared the view that option 1 seemed to be the simplest and cleanest for two reasons:

It’s easy to remember: “Anything else besides a JSON null value means the value is undefined”.
If a developer wants to set the value to be explicitly null, then the developer would have only one completely unambiguous way to express that:

=markus<+email>&/&/null

To be clear, this means would mean either of the following statements about Markus’s email...

=markus<+email>

=markus<+email>&

...if alone in the graph without the existence of a literal node—would mean that the value is undefined.

Animesh asked how a developer can do a test for a value in the $if branch of a policy statement. Markus replied that our XDI policy statements can match all of these states precisely.

Since Markus had to leave the call at this point, Drummond proposed that all TC members cook on this proposal:

That if a developer wants to set the value of an attribute to be explicitly null, the developer can do this by setting the value to JSON null, and this is fully round-trippable.
That either of the other two attribute value states (no value context node or no literal node) mean that the value of the attribute is undefined.

Use of Ampersand

Steve brought up that the use of & as a character might be very confusing to developers because in other programming languages it’s meaning is “reference to”, so our use of & to mean hasValue is directly the opposite of the use of ampersand in C++ and Perl to mean AddressOf.

However as we discussed whether there were any other options, we went deeper into the meaning of ampersand as the predicate for a literal. Once Steve understood this usage, it suddenly made much more sense to him, and he withdrew his objections to the ampersand syntax.