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] Minutes: XDI TC Telecon Friday 2014-08-15


Markus, thanks for posting these. See a few additions inline.


On Sat, Aug 16, 2014 at 9:58 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Minutes


Following are the minutes of the unofficial telecon of the XDI TC at:


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

ATTENDING

Les Chasen
Peter Davis
Courtney Brown
Drummond Reed
Dan Blum
Hubert Le Van Gong
Jim Fournier
Joseph Boyle
Markus Sabadello
William Dyson
Phil Windley
Eno Jackson
Ning Zhang
Brian Wu

GUESTS
Steve Greenberg

REGRETS

NEWS & UPDATES

PRESENTATIONS/DISCUSSIONS

Report from XDI editors subcommittee

https://wiki.oasis-open.org/xdi/XdiOneSpecs
https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook


Chair Peter Davis ran through the JIRA review process that the Editors SC is using to take action on editorial items and prioritize plenary items for the TC. 

Value context nodes must have a literal

A while ago the TC decided that value context nodes must have a literal, i.e. the following situations are valid:


An attribute has a string value:

=markus<#email>&/&/"..."


An attribute has a null value:

=markus<#email>&/&/null


An attribute has no value (undefined):

=markus//<#email>


The following is not valid:

=markus<#email>//&


Joseph asked about this statement:

=markus<#email>&/&/


That statement is not valid because the object is not a valid JSON value.


Joseph also made the point that all the statements shown are statements and not addresses. Only XDI contexts are addresses.


Joseph asked if both value nodes and literal nodes were needed. Drummond explained that the TC spent several calls discussing this about two years ago when the decision was made to add value nodes. He referred Joseph to the minutes of those meetings and suggested that if he had an alternate proposal, to write it up and bring it before the TC.


We also spent some time with an updated version of the Neustar Graph Editor:

http://neustar.github.io/xdi-grapheditor/xdi-grapheditor/public_html/index.html

The TC once again congratulated Hubert and Jingning for this piece of work.


For diagrams of XDI graphs, Drummond was in favor of introducing a “short form” where the contextual arc of the value node is combined with the literal.

Since you cannot have a value context node without a literal, this would be a lossless simplification.


To be precise, "short form" diagrams would remove one arc and one node from "long form" diagrams: literal arcs and literal nodes. Literal values would still be shown, they would just be shown next to the value node instead of the literal node. As the minutes point out, since if you have a value node you MUST have a literal value, no information is lost (and the resulting diagram is just more compact). In fact the only downside of the short form is that it doesn't display 100% of the information that is present in all the XDI statements represented in the graph. However showing the literal arc and literal nodes in the long form should only be needed in XDI graphs intended for audiences who: a) are new to XDI, and b) need to precisely understand the structure of XDI statements. For all other audiences, short form diagrams will be smaller, less complex, and less confusing, so that's why I am a big advocate of the short form.
 

Drummond also suggested the TC should define the basic rules for diagrams of XDI graphs.


In fact Joseph and I have an action item to write it up in the next Working Draft of XDI Core.
 

Markus then began a discussion on how $get, $set, and especially $del operations behave in the above situations.


Starting graph: =markus<#email>&/&/"..."


#1 Operation: =sender[$msg]!:uuid:1234$do/$get/=markus<#email>&

Result: =markus<#email>&/&/"..."


#2 Operation: (=sender[$msg]!:uuid:1234$do/$get)=markus<#email>&/&/"..."

Result: =markus<#email>&/&/"..."


#3 Operation: =sender[$msg]!:uuid:1234$do/$del/=markus<#email>&
Graph after the operation: =markus//<#email>

Result: (empty graph)


#4 Operation: (=sender[$msg]!:uuid:1234$do/$del)=markus<#email>&/&/"..."

Graph after the operation: =markus<#email>//&   <-- not valid

Question: Does that last $del operation delete the literal arc AND the value context node?

Graph after the operation: =markus//<#email>   <-- like this?


Starting graph: (empty graph)


#5 Operation: (=sender[$msg]!:uuid:1234$do/$set)=markus<#email>//&

Question: Is this an invalid operation? Or would this create a literal with a null value?

Graph after the operation: =markus<#email>&/&/null   <-- like this?


Drummond suggested that it should be parallel with the $del operation, i.e., it should automatically create a null value. Markus pointed out that this would be consistent with the behavior of $set, which is that it never produces an error (provided that it is authorized).


A final point: although we are close to consensus on this conclusion, we did not have consensus because Joseph asked for time to study it further. We asked Joseph to come back with any questions or alternate proposal no later than next week's call so we can decide if we have consensus or we need to hold a vote.
 

Governor link contracts, and link contract initiation

Dan requested feedback on governor link contracts in the XDI Policy spec draft:

https://www.oasis-open.org/committees/download.php/53649/XDIPolicyDraft%20v6.docx

https://wiki.oasis-open.org/xdi/LinkContractPattern


Dan explained that his draft is mostly based on TC wiki pages related to link contracts and policies. He is however not sure if all examples in his draft are still accurate after the “link contract shift” and “notation shift”, and would like some help updating them.


We then talked about the “governor link contract”. Dan’s understanding is that the governor link contract allows an authorizing authority (AA) to write a new link contract instance into a requesting authority’s (RA) graph, and then at a later time possibly modify it.


Drummond gave us a walkthrough of a typical flow. The RA publishes a link contract template. The AA creates a link contract instance based on the template. It is desirable (although not strictly necessary) that both parties have a copy of the new link contract. This means that the AA sends the new link contract instance via a $set operation to the RA’s XDI endpoint. This operation of course must itself be authorized by a link contract. This is the purpose of the “governor link contract”. Drummond explained that the governor link contract might have rules in its policy that determine what link contract instances to accept (e.g. not from minors). Drummond also emphasized that the address of the governor link contract can be algorithmically determined from the address of the link contract template.


Dan and others on the TC didn’t yet feel comfortable enough with the structure of the governor link contract. We ran out of time going into more detail but agreed we should 1. continue this discussion as the first item on next week’s agenda, and 2. schedule a separate, dedicated call early next week. The details of this call will be announced on the TC mailing list, and any TC member interested in this topic is invited to participate.


ABNF after notation shift

Joseph requested help with the XDI ABNF, explaining that after the notation shift it would not be possible to have a common ABNF that covers all serialization formats.

https://wiki.oasis-open.org/xdi/XdiAbnf


We did not have time to discuss this topic.


Actually, we did discuss this topic, and specifically agreed that Joseph and Drummond would schedule a full working day when Drummond is in SF on the weekend of August 23/24 to work on the ABNF, the graph notation format documentation, and the rest of the editorial suggestions to XDI Core. Assuming Joseph and I can arrive an ABNF we both like, we would then present that for review by the TC.

=Drummond 


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