[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-08-15
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)
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
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. Drummond also suggested the TC should define the basic rules for diagrams of XDI graphs.
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).
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.
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]