XDI TC Notes

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

Date: Monday, 7 September 2015 USA
Time: 10:00AM - 11:30AM 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

Markus Sabadello
Drummond Reed
Les Chasen
Joseph Boyle
Lionel Wolberger

REGRETS

XDI Core: Spec Drafting Update

Drummond is still drafting the next new sections but will review several revisions to the previous upload:

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

We talked about the two updates Drummond has made:

He changed the name of the fourth entity instance type—previously “Order”—to “Ordinal” as suggested by Joseph.
He added a short new subsection at the end of the Variables section called Reserved Variables. This is important because certain $words are indeed reserved for special functions in the XDI protocol.

XDI Core: Group Membership Using $has Relations

Drummond introduced us to the table at the start of the “Core Relations” section, which is inspired by the Wikipedia Has-a article. For all the different kinds of relations that are possible in object modeling, the table shows the matching XDI construct.

Drummond explained that in XDI no separate construct is needed for type/instance and type/subtype relations, since this distinction is expressed by XDI context symbols.

Drummond realized that the Aggregation Relations ($has) section of Core needs to specify how membership in a +group is defined in XDI. His precise proposal is:

+group/$has/=member

The actual text he proposes is along the lines of: “If a +group needs to specify its members (=person), it MUST use $has relations.” It will also say that this is a common requirement in XDI Messaging, when an XDI message is intended to be sent to an all members of a group.

We noted in the discussion that a group MAY include a member who is identified only by a relative personal identifier within the group. Examples:

+xdi.org/$has/+xdi.org=~markus

+xdi.org/$has/+sabadello.family=~markus

For this reason Drummond will update the text in the Aggregation Relations section to remove the warning against having a $has relation to a node in the same subgraph as the parent of the $has relation.

XDI Core: Contextual Description Pattern

Drummond also proposes to add an explanation of the contextual description pattern to the Aggregation Relations ($has) section of Core. A contextual description is a nested context node that describes an entity that exists independently of that context—which will be true the majority of the time with $has aggregation relationships. A contextual description always exists in the context of (and is owned by) the aggregate entity. For example, if we apply this to groups and members:

+group/$has/=member
+group <== contains subgraph independently describing +group

(subgraph OWNED by the group)

=member <== contains subgraph independently describing =member
(subgraph OWNED by the member)

+group=member <== contains subgraph contextually describing the
group member (subgraph OWNED by the group)

Contextual descriptions are extremely useful in XDI. A simple example:

+xdi.org=markus<#membership><#number> <== contextual attribute

A “membership number” attribute would not make any sense on =markus as a root-level entity, because it would be unclear what membership it described. But as an attribute of =markus in the context of +xdi.org, it makes sense.

Another example of contextual description is when a person needs to ascribe attributes to another person that exist only in the context of their relationship, such notes in a personal contact record (e.g., a Microsoft Outlook or Google Contact entry). Example:

=drummond=markus<#notes>/&/”great developer” <==contextual description

Les said he liked this pattern, and he could see it being used to ascribe roles to members of a group.

Lionel asked whether the XDI address +group=member implies the statement +group/$has/=member.

In exploring this question, we noted that with XDI context trees, it is possible for a group to have a $has aggregation relationship with a group member whose XDI identity exists only inside that group’s context tree as a relative personal identifier. Example:

+xdi.org//=~markus               <== contextual relationship
                                    (composition)
+xdi.org/$has/+xdi.org=~markus   <== aggregation relationship

In this case, the group member’s identity would be deleted if the group was deleted (as is the case with composition relationships). However Drummond argued that there are still two different relationships represented here, and the fact that the aggregated node (+xdi.org=~markus) would be deleted if the aggregate node (+xdi.org) is deleted does not change that +xdi.org=~markus is a member of +xdi.org due to the $has aggregation relationship.

Markus noted that we need to be very precise in our wording. He used this example:

=drummond=markus<#notes>

In this example, there is not a composition relationship between =drummond and =markus. There is only composition relationship between =drummond and =drummond=markus.

Drummond pointed out one more question that he felt should be addressed in this section: when should you use the contextual description pattern vs. the inner graph pattern?

+group//=member
+group <== independent description of the group

=member            <== independent description of the member
+group=member      <== contextual description of the group member
(+group/=member)   <== inner graph description of the relationship

between the group and the member

In our discussion it quickly became clear:

A contextual description describes the entity in context, but does NOT describe the relationship.
An inner graph describes the relationship and does NOT describe the entity in context.

Drummond noted that this is why a link contract requires the inner graph pattern—it describes the relationship and not the entity in context.

Messaging Walkthrough and XDI Channels

We will continue Markus’ “messaging walkthrough” and a variation of this flow called “change of address walkthrough” so that Markus can raise questions and issues he is running across. See:

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

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

Markus gave an update that he’s completed the diagrams and message descriptions for a complete change-of-address scenario. The walkthrough explains all the details of:

The agents and endpoints
The link contracts
The messages and nested messages

Drummond said that the only feedback that came out of the review was:

Proposing specific reserved variables for link contracts.
Proposing where those are defined in XDI messages.

NEXT REGULAR CALL

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

xdi message