XDI TC Minutes

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

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

ATTENDING

Les Chasen

Animesh Chowdhury

Dan Blum

Joseph Boyle

Markus Sabadello

Phil Windley

Drummond Reed

GUESTS

Steve Greenberg
Andy Dale

PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

This week Markus Joseph have discussed best practices for collaboration on the spec drafts on Github. Currently there is one account representing the OASIS XDI TC. Each editor then has his/her own account.

Markus recommends that, as long as an editor works primarily on a spec that editor is primarily responsible for, they can just work against the master repository. However if another editor wants to make a contribution to another spec maintained by the primary editor, then that secondary editor should create a branch or a fork.

Steve suggested that the same git workflows apply well to document development. All work should be performed in a branch and the master branch should always be release quality.

Phil suggested the following specific set of contribution steps:

Fork
Clone your fork
Hack (write) away
If you are adding new functionality, document it in the README
If necessary, rebase your commits into logical chunks, without errors (this is mostly useful if you commit ‘unsafe’ stages, where the doc wouldn’t build, for example, so that there all commits are buildable).
Verfiy your changes by running the test suite, and adding additional tests if able. (Joseph noted that the “test” in this case is proper display in the browser.)
Push the branch up to GitHub
Send a pull request

Joseph agreed that this should work well. He asked about whether editors would still need to branch within their own fork and then merge back into master or not.

Drummond asked about recommendations for XML editors. Markus said he plans to use Eclipse, which also has nice integration with Github. Steve said that Oxygen is money well spent, but among free tools he strongly recommends Emacs (tutorial, nXml mode, Using nXml with DocBook).

Drummond mentioned that today was our self-imposed deadline for first drafts, but he is not nearly far enough on his Core text yet. Joseph said that he plans to have a draft of the ABNF section of Core by the end of the weekend. Markus said he’s been doing some initial drafting on Messaging but hasn’t pushed it yet.

Link Contract Terminology: Requesting Party and Authorizing Party

In working on implementing link contract initiation with Andy, Drummond and Markus realized that the terms “initiator” and “acceptor” did not work under all the different use cases as the terms “authorizing party” and “requesting party”. This substitution has already been implemented on https://wiki.oasis-open.org/xdi/LinkContractPattern.

Dan agreed that this terms made sense. Markus noted that both parties are XDI authorities, but in this context only one of them is doing the authorizing.

#DECISION: We will adopt these terms for describing the parties to a link contract.

DECISION POINTS FOR THIS CALL

Graph Notation

Drummond started a thread on the email list about revisions to our graph notation, which is important because we will be using this notation in XDI Core:

Drummond said the email discussion was very productive, and that his recommendation was that the full proposed notation could be adapted to two simplified forms:

Shapes only would not show the multiplicity characters inside shapes.
Values only would not show literal arcs.

#DECISION: We will use this new graph notation starting in XDI Core.

Joseph noted there is an existing entity-relationship diagram notation widely used in database design, where entities are rectangles, attributes are ovals, and relations (a different concept from XDI relational arcs which are aliases) are diamonds. Alignment with existing database terminology would greatly aid XDI acceptance since SQL is the closest existing analogy to XDI.

Drummond noted the the enhanced entity-relationship model also includes superclasses, subclasses, specialization, and generalization, all of which also apply to the XDI graph model.

Terminology: Collection and Member

In looking at the original XDI Core spec outline a few weeks ago, Markus noted that the terms “class” was used twice—once for context symbols (+ and $) and once for a context function (square brackets). To avoid this confusion, Drummond suggests that we refer to the context function as a collection and to instances inside this collection as members.

This is already reflected in an update to the Graph Model Structure wiki page.

#DECISION: We will adopt this terminology change.

No Nested Members, Only Nested Collections

In working on the ABNF, Drummond felt that the XDI ABNF would be simpler and more regular if members of a collection could not be nested. Markus then suggested an ingenious solution, which is that whenever you need to nest members of a collection, you just nest the same collection. The most immediate example of this is nesting of XDI messages, which is a proposed requirement of XDI messaging. XDI messaging also requires that the members of the nested collection be ordered.

This is an example of the syntax for nested XDI messages before the proposed change. Note that !:uuid:1234 is an unordered member of the [$msg] collection, and #0 is a nested member of !:uuid:1234.

=sender[$msg]!:uuid:1234#0

=sender[$msg]!:uuid:1234#1

=sender[$msg]!:uuid:1234#2

Here is what the same pattern would look like after the proposed change:

=sender[$msg]!:uuid:1234[$msg]#0

=sender[$msg]!:uuid:1234[$msg]#1

=sender[$msg]!:uuid:1234[$msg]#2

The difference is that second the [$msg] collection is simply nested inside a member of the first collection.

#DECISION: We will simplify the ABNF to not allow nesting of collection members.

Steve noted that, when applied to XDI messaging, this of course raises the issue of transactional integrity. Drummond acknowledged that this is a very important issue that has been discussed many times in the past and will have to be covered in the XDI Messaging spec. Animesh noted that transactional integrity is still an issue even with single messages because they may contain multiple operations.

We noted that this issue should go on next week’s agenda for discussion relative to the Messaging spec.

Attributes Not Containing Entities

Another simplification Drummond realized while working on the ABNF is that attributes should not need to contain entities. He was not able to come up with a single good example of where that would be needed. A discussion with Markus yielded the same outcome. If attributes cannot contain entities, then the overall structure of the graph can be strictly divided into four ordered “spaces”:

Root space contains the tree of all root nodes. A root node can have contextual arcs to other roots, entities, and attributes (but not values).
Entity space contains the tree of all entity nodes. An entity node can have contextual arcs to other entities and to attributes (but not values).
Attribute space contains the tree of all attribute nodes. An attribute node can have contextual arcs to other attributes and (if not a collection) to a value.
Value space contains a single dimension of value nodes, the terminal (leaf) nodes of the context graph, and a corresponding set of literal nodes, which have a zero-or-one relationship with value nodes.

The ordering rule is simple: once the path of an XDI address crosses from one space into another, it MUST NOT “back up” into a previous space.

Dan wondered if perhaps a log file might be an example where an attribute would need to contain an entity. Drummond explained that this use case, like all the others he and Markus had considered, is probably better modeled with a relational arc, possibly to an inner graph.

Phil favored this approach because of the general rule that it is better to start strict and then loosen later if necessary. Dan agreed because simple is good when it comes to the XDI graph model.

#DECISION: In XDI Core 1.0, attributes will not be allowed to contain entities.

Animesh pointed out that an attribute should not be able to have a $ref to an entity. Drummond pointed out that this is actually an example of the equivalence relation rule, which is that the node type of a target of an equivalence relation MUST be the same as the node type of the source.