XDI TC Minutes

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

Date: Monday, 8 June 2015 USA
Time: 10:00AM - 11:30AM Pacific Time

ATTENDING

Drummond Reed
Markus Sabadello
Les Chasen
Joseph Boyle

REGRETS

Phil Windley
Peter Davis

AGENDA

Variables Section in XDI Core

Drummond is continuing his work drafting this section of XDI Core 1.0, which is very closely based on the XDI Variables page on the wiki:

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

He explained that he revisited a subject we talked last week: named variables, and the desire to be able to use human-readable names instead of just abstract $digits such as {$1}, {$2}, etc. His proposal was to use relative $words for this purpose, e.g.,

{$_price}
{$_temp}
{$_product-name}

Markus pointed out that reserved classes are used for special variables in messaging—”reserved variables”—such as:

{$from}

{$to}

Any other $words used as a variable would be typed variables just like any other typed variable, e.g.:

{$uri}

{$iri}

Markus said one concern about using the $ space is that developers might think that human-readable named variables have some special property like the reserved variables.

Drummond agreed. He also pointed out that in fact this whole question with named variables might be solved by taking a different approach: using relative XDI names in the # space, e.g.:

{#_price}
{#_temp}
{#_product-name}

With this approach, it would not matter whether it is a human-readable name or a number that is used as the relative identifier. The semantic meaning would always be that the variable ID is relative and does not carry any global semantics.

We also recalled that we had consensus about not allowing the pattern {name} which we had explored for a short while.

XDI Registry and Discovery Services

Markus led a review the basic XDI discovery process, e.g. what discovery requests and responses look like, by reviewing the content of:

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

In its most basic form, the purpose of XDI discovery is to find an XDI endpoint IRI, given a peer root address such as (=markus) or (=!:uuid:1111).

We explored two different approaches to performing discovery on multiple peer roots in a sequence:

(https://xdi.example.com/)(+!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)(urn:isbn:0451450523)

Option 1: $get on

a. (https://xdi.example.com/)<$xdi><$uri>

b. (https://xdi.example.com/)(+!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)<$xdi><$uri>

c. (https://xdi.example.com/)(+!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)(urn:isbn:0451450523)<$xdi><$uri>

Option 2: $get on

a. (https://xdi.example.com/)<$xdi><$uri>

b. (+!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)<$xdi><$uri>

c. (urn:isbn:0451450523)<$xdi><$uri>

XDI endpoint URI e.g. for c:

(https://xdi.example.com/)<$xdi><$uri>/&/"https://....."

We also discussed the the $proxy message parameter defined by XDI Messaging:

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

We agreed that the $proxy parameter requests server-side execution of the discovery process, whereas options 1 and 2 above determine the individual steps of the discovery process.

We then talked about XDI registries which can answer discovery requests. An important realization was that both registration and discovery simply re-uses the primitive XDI messaging functionality, without adding any extra rules. This means that all regular XDI features can be used for implementing and running a registry, e.g. link contracts. One consequence seems to be that the XDI Discovery spec is going to be very light-weight and that it would mostly be laid out as a profile of XDI Messaging and other specs.

In our review, we realized several updates to this wiki page were needed.

#ACTION ITEMS:

Update the Discovery wiki page for the star shift.
Update the Discovery wiki page for the different options for multi-endpoint requests.
Update the Discovery wiki page for $iri.

NEXT CALL

THERE WILL BE NO CALL NEXT WEEK due to multiple TC members travelling.