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: XDI TC Notes Unofficial Telecon Tuesday 2017-02-21


XDI TC Notes


Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Tuesday, 21 February 2017 USA
Time: 9:00AM - 10:00AM Pacific Time (17:00-18:30 UTC)


The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Phil Windley
Drummond Reed
Markus Sabadello

NOTES

Spec Updates

Quick report by Markus on some minor updates to the Messaging and Link Contracts specs.

Markus reported that he made sure the current spec WDs reflect our recent discussions on the use of $contract, $do, and $do$if keywords.


Markus also gave a quick demo of the new $del$if deletion policy branch of link contracts.

XDI Graph Garbage Collection

While demo'ing the $del$if deletion policy branch, we noticed that sometimes after a $del operation, certain "leftover" nodes and arcs seem to remain in an XDI graph.

For example, if the following statements exist in a graph:


=markus<#email>/&/"markus@danubetech.com"
=markus/#friend/=drummond


… and if then a $del operation is executed on the =markus/#friend/=drummond statement, then the following graph remains:


=markus<#email>/&/"markus@danubetech.com"
//=drummond


Should the =drummond context node also be deleted from the graph?  


Pro argument: Its only function was to be the object of the relational arc, and without the relational statement, the object context node is not needed anymore.

Con argument: The empty context node may have been in the graph before the relational arc, and deleting a relational arc should have no effect on its subject and object context nodes.


Phil said this is similar to garbage collection in programming languages like Java, where objects are automatically deleted if they have no more references. Markus said there may be privacy implications through "graph fingerprinting", i.e. the existence of certain "leftover" nodes and arcs could hint at contents that may have existed in the graph at some point in the past.


We did not resolve this issue.

Issues with $ref/$rep Equivalence Relations

Markus raised the following set of questions on this topic. First, the XDI Core Spec says the following about $ref/$rep:


"A reference relation asserts that two context nodes represent the same logical resource and the object node is canonical. In this case only the object node may contain a subgraph describing the resource."


This means that e.g. the following graph is not valid:


=!:uuid:1a1a/$ref/=!:uuid:1111

=!:uuid:1a1a<#email>/&/"me@gmail.com"


Drummond agreed this was correct—the node =!:uuid:1a1a cannot have both a $ref and a subgraph.


Question: Is the following graph valid?


=!:uuid:1a1a/$ref/=!:uuid:1111

=!:uuid:1111<#email>/&/"me@gmail.com"

=!:uuid:2222[$msg]@~0$do/$get/=!:uuid:1a1a<#email>


Drummond and Phil agreed that this graph is valid because the object of the $get statement is simply an address in the graph, and that address fully resolves (even though it goes through a $ref).


Question: Is the following graph valid?


=!:uuid:1a1a/$ref/=!:uuid:1111

(=!:uuid:1a1a/=!:uuid:2222)$contract$do/$get/


We identified the issue: that a node that is the object of a relational arc may have one or more valid addresses in the graph, whereas a relational statement can only have one address as the object.

Our conclusion was that a drawing of the graph, in order to have all the information in the source XDI statements that produce the graph, MUST include the XDI address of the object of each relational statement as an annotation to the relational arc. It SHOULD be placed at the end of the relational arc arrow.

Graph reflecting the second example above:

xditc.png

Markus briefly discussed an alternative approach which would allow context nodes to have both a $ref arc and also a subgraph. This approach however would make that subgraph "unreachable":




xditc2.png

We quickly reached consensus that the first approach is preferable.

Finally, an example of a graph involving an inner root with multiple addresses as a consequence of $ref arcs:

xditc3.png

Health Care Use Case

If there is still time, let's discuss the use of XDI messages and link contracts for a patient/doctor interaction use case.


We did not have time to further discuss this topic.

NEXT REGULAR CALL

The next call will be the following week at the usual time (Tuesday 9AM PT). The link where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing






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