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: Minutes: XDI TC Telecon Friday 2014-06-13


XDI TC Minutes


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


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

ATTENDING

Phil Windley
Dan Blum
Joseph Boyle
Markus Sabadello
Drummond Reed
William Dyson

GUESTS

Eno Jackson
Brian Wu

REGRETS

NEWS & UPDATES

William Dyson joins XDI TC

The XDI TC welcomed WIlliam Dyson as a new member of the XDI TC for Planetwork.

PRESENTATIONS/DISCUSSIONS

XDI policies

Dan has uploaded version 5 of the XDI policy spec draft and is looking for help with the XDI syntax:

https://www.oasis-open.org/committees/document.php?document_id=53343&wg_abbrev=xdi


We agreed the XDI policy spec draft should be based on patterns after the “notation shift”. Markus noted that the XDI2 codebase has not yet been updated accordingly, and that this work would begin on a separate branch of the code. This can be communicated during the RN launch tour.


Markus will try to work on the XDI policy spec draft to help Dan update the XDI syntax.


For the Respect Network launch, Dan would like to see more browser-viewable versions of the spec, as well as appropriate links from the OASIS site and wiki. Dan could use Joseph’s help with the Docbook process, and with deploying the browser-viewable versions.

Notation shift

After the “link contract shift”, in which link contract patterns have been changed to use the XDI inner root feature, we are now discussing the “notation shift”, which involves the following:

- Abandoning the rule that the source and target context node of a relational arc have to be inside the same inner graph

- Abandoning the inner root “short notation”


Before the “link contract shift”, a link contract looks like this:

[=]!:uuid:1111$to[=]!:uuid:2222$from$do/$get/[=]!:uuid:1111<#email>


After the “link contract shift”, but before the “notation shift”, a link contract looks like this

([=]!:uuid:1111/[=]!:uuid:2222)$do/$get/([=]!:uuid:1111/[=]!:uuid:2222)[=]!:uuid:1111<#email>


Or in “short notation”:

[=]!:uuid:1111/[=]!:uuid:2222/($do/$get/[=]!:uuid:1111<#email>)


After the “notation shift”, a link contract looks like this:

([=]!:uuid:1111/[=]!:uuid:2222)$do/$get/[=]!:uuid:1111<#email>

We went over these examples using Neustar’s XDI Graph Editor:

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

Originally written by Hubert Le Van Gong of Neustar, Jingning Zhang (University of Illinois) has also contributed major improvements in version 2. The TC once more thanked them for their work, and acknowledged how useful and effective the tool is for visualizing concrete issues such as the “notation shift”.

Before the “notation shift”:

Screenshot from 2014-06-13 19:07:00.png

After the “notation shift”:

Screenshot from 2014-06-13 19:06:40.png

In the second picture, it is clearly visible that the relational arc which represents the $get permission starts at $do under the inner root, and ends outside the inner root. In other words, the target of the permission arc is exactly the context node to which the permission applies. In the serialization, this removes the “duplicated” inner root on the object side. We recalled that Animesh had been a strong proponent of this approach.

Joseph asked if the “notation shift” affected the Core and/or Messaging spec. Markus’ opinion was that it affects both. The Core spec would have to explain the fundamental mechanics of inner roots, while the Messaging spec would have to explain how inner roots are used for messaging.

Joseph asked if it was correct to use [=]!:uuid:2222 as a predicate. Drummond explained that an inner root is a reification of a subject and a predicate. Since the “link contract shift”, link contracts are essentially modeled as reifications of a relationship. If the relationship is between [=]!:uuid:1111 and [=]!:uuid:2222, then [=]!:uuid:1111 is the subject, and [=]!:uuid:2222 is the predicate, and together they form an inner root. Drummond also reminded Joseph that in XDI it is perfectly okay for a relational arc to consist of multiple subsegments.

We noted that that since the “short notation” would go away after the “notation shift”, the ABNF would have to change accordingly to allow at most 2 segments inside a cross reference. Any parser code of an XDI implementation would also have to change.

After discussing link contracts, we also went over an example of an XDI message, and how it would change with the “notation shift”:

Before the "notation shift", short notation:

[=]!:uuid:1111[$msg]!:uuid:1234$do/$set/([=]!:uuid:1111/#friend/[=]!:uuid:2222)
[=]!:uuid:1111[$msg]!:uuid:1234$do/$get/[=]!:uuid:1111<#email>

Before the “notation shift”, regular notation:

([=]!:uuid:1111[$msg]!:uuid:1234$do/$set)[=]!:uuid:1111/#friend/([=]!:uuid:1111[$msg]!:uuid:1234$do/$set)[=]!:uuid:2222
[=]!:uuid:1111[$msg]!:uuid:1234$do/$get/[=]!:uuid:1111<#email>

After the "notation shift":

([=]!:uuid:1111[$msg]!:uuid:1234$do/$set)[=]!:uuid:1111/#friend/[=]!:uuid:2222
[=]!:uuid:1111[$msg]!:uuid:1234$do/$get/[=]!:uuid:1111<#email>

We also discussed the difference between the following two operations:

[=]!:uuid:1111[$msg]!:uuid:1234$do/$get/[=]!:uuid:1111<#email>
([=]!:uuid:1111[$msg]!:uuid:1234$do/$get)[=]!:uuid:1111//<#email>

While the first is an operation on an XDI address, the second is an operation on an XDI statement. This distinction works in a similar way for $get, $set, and $del, and it works before and after the “notation shift”.

We concluded that among the participants of the call there was a consensus for moving ahead with the “notation shift”. We would still like to get feedback (at a minimum) from Animesh Chowdhury and Peter Davis before making a final decision.

We noted that a lot of wiki pages will have to be updated. Dan’s opinion was that we should avoid duplication of content between the XDI spec drafts, and OASIS wiki pages.

Cloud names and cloud numbers

Dan asked about the terminology of “cloud name” and “cloud number” on one hand, and “XDI address” on the other hand. Drummond explained that “cloud name” and “cloud number” are marketing terms, while “XDI address” is a technical term. A similar distinction existed in the past, when “i-name” and “i-number” were the marketing terms based on the “XRI” technical term.

We also discussed the rationale behind the syntax of cloud numbers, which are persistent members of the [=] and [+] entity collections, e.g.:

 cloud name:     =danb              (1 context node in the graph)
 cloud number: [=]!:uuid:1111     (2 context nodes in the graph)

 Historically:

 i-name:   =danb                   (1 subsegment)
 i-number: =!A45B.C6F.3326.4BE1    (1 subsegment)

Report from XDI editors subcommittee

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

https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook


We did not have time to discuss this topic.

Spec variable format convention

The question has come up how “spec variables” (not the same as “XDI variables”) should be written.

Example of old approach:

<--from-peer-->/$set/<--from-->[$msg]<--msg-id-->

Example of proposed new approach:

%FROM-PEER/$set/%FROM[$msg]%MSG-ID

We discussed this topic very briefly but did not come to a conclusion.


XDI signatures

Continue to discuss Peter’s updated XDI signature proposal:

https://lists.oasis-open.org/archives/xdi/201405/msg00030.html


We did not have time to discuss this topic.

NEXT CALL

The next call is next week at the regular time.




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