XDI TC Minutes

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

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

ATTENDING

Markus Sabadello
Phil Windley
Drummond Reed
Les Chasen
Dan Blum
Animesh Chowdhury

REGRETS

Joseph Boyle (sick)

GUESTS

Steve Greenberg
Andy Dale

NEWS & UPDATES

None scheduled.

PRESENTATIONS/DISCUSSIONS

Next Steps on Working Drafts

Joseph was not able to attend so we did not go over the additions/corrections we want to make to produce XDI Core 1.0 Working Draft 02, including:

MIME types for serialization formats.
Formatting improvements.
Adding missing sections.
Improved Github merging process.

We will take these up on next week’s call.

Merging Graphs and Graph-Relative vs. Authority-Relative Statements

We will contain discussion about whether certain statements in an XDI graph should be “graph-relative” or “root-relative”, e.g.:

<$public><$key>&/&/”...”

or “authority-relative”, e.g.:

=markus<$public><$key>&/&/”...”

This was the main topic of the call. We used the following “Alice and Bob” XDI graph diagram to provide examples during the discussion:

Markus started by saying that there are two consequences of taking XDI statements that were formerly graph-relative and making them authority-relative:

It means a client must know the XDI address of the authority before the client can request even data available under a public link contract.
All statements by a first authority about a second authority must be in the context of the first authority.

Markus explained that he was now generally comfortable with both of these implications of authority-relative statements, but he pointed out that there could be some other implications that arise later that we don’t realize yet.

Animesh then poised a question about how XDI search crawlers would access a public link contract if the crawler does not know the XDI authorities represented within a specific graph. Andy pointed out that this is a feature, not a bug, and that such XDI authorities could easily publish their XDI addresses on the Web if they wanted their public XDI data to be crawled.

Drummond subsequently realized there is an elegant solution to this based on using an XDI $public$do/$is()/… statement that would satisfy both Animesh and Andy. He will make a separate post to the mailing list about that.

Animesh then asked a question about how XDI graphs and authorities would deal with the need to change an XDI cloud number (i.e., an persistent XDI address) for the authority. He posited that one use case for this was if the authority lost control of the XDI cloud number or it became “polluted”.

Andy pointed out that this should not happen with XDI; it should always be possible to restore control to the rightful authority. However Drummond pointed out that there are use cases, such as a merge between two businesses, where one cloud number would be “retired” in favor of another successor cloud number. This of course could be done using a $ref statement.

However there was a consensus that we do not have a silver bullet for the larger question of what happens when you need to change the primary key representing an entity in XDI. This is the same challenge you have with changing a primary key in any other database or directory system.

To conclude the call, Drummond asked if there were any final concerns about the rule that statements about an XDI entity must be universal, i.e., they can to be copied to any XDI graph without conflict, whereas statements about attributes of an XDI graph apply only to the specific XDI graph instance identified in the statement and cannot be copied to any other XDI graph without remaining relative to that specific graph root node.

No further concerns were raised, so we have a consensus about this rule.

It was agreed that on next week’s call, we would address the other outstanding topics in light of this rule, i.e.: