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: Minutes: XDI TC Telecon Friday 2013-07-26

XDI TC Minutes

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

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


Peter Davis

Animesh Chowdhury

Phil Windley

Markus Sabadello


Drummond Reed
Joseph Boyle




Animesh has been working on a Java library for accessing XDI-based Personal Clouds. For example, it can open a Personal Cloud, read and write data, and manage permissions. This library provides a simple, high-level API to developers and uses XDI discovery and messaging under the hood:


The following is some sample Java code that uses the library:

// open my own personal cloud

PersonalCloud cloud = PersonalCloud.open(XDI3Segment.create("=markus"), "s3cr3t", null,"");

// store my profile info

ProfileInfo profileInfo = new ProfileInfo();
profileInfo.setPhone("+43 664 3154848");




While working on the above mentioned Java library, Animesh attempted to first create a new link contract, and then at a later point in time delete it again. In doing so, he observed a seemingly inexplicable behavior of “the link contract not going away” after a $del operation. Markus investigated the issue, suspecting a bug in the XDI2 server. It turned out however, that the problem was not actually one of the XDI2 implementation, but rooted deeper in the XDI graph model, and more specifically XDI inner roots.

A detailed walkthrough of the problem can be found here:


Basically, the problem is that deleting a context node currently deletes all its sub-contexts nodes as well as all their relations. But it does NOT delete inner roots, because strictly speaking the inner roots are not sub-contexts of the context node that was originally deleted. Markus suggested that this behavior should be changed, and inner roots should be deleted too. This would then meet the “expected behavior” as described in the above PDF.


Joseph and Markus have been working on the XDI spec drafting process, Docbook templates, Github repositories, etc., with Chet Ensign and Paul Knight of OASIS.

A list of currently planned XDI 1.0 specs can be found here:


Markus has collected files relevant to the spec drafting process in a Github account:


This contains the following repositories:
xdi-spec-dita: DITA template files created earlier by Bill Barnhill

- xdi-spec-openoffice: Open Office (ODT) template files

- xdi-spec-docbook: Docbook template files

Markus reported that he created experimental xdi-core and xdi-messaging Docbook spec files, as well as a project file for the oXygen XML editor. These files can be found in the above “xdi-spec-docbook” repository in the “xdi/” folder.

The general process with Docbook is that one edits an XML file using oXygen, XMLMind or other XML editor, and then “transforms” the XML source to output formats such as HTML, PDF, etc. The XML stylesheets required for doing so have been provided by OASIS and can also be found in the above xdi-spec-docbook repository.

One open question is whether we want to use Github for managing spec files, collaboration, and revision control. Peter reported that he had previously used Subversion for his spec work. We agreed that most likely we would not have a situation where many people will be working concurrently on the same spec. Rather, one of the editors would be “leading” a certain spec, and managing contributions from other editors and TC members.

Peter explained one feature that would be nice to have is “red lines”, i.e. producing documents that can show the differences between different working draft versions.

# JOSEPH AND MARKUS: Create initial Docbook files for remaining XDI specs and test the drafting process.

# ALL: Discuss what to use for revision control and collaboration (Github?)


We continued our review of mechanisms for XDI message authentication and authorization and how they align with OAuth and PKI.

These mechanisms will be covered in their own “XDI Security Mechanisms V1.0” spec:


For proposals to this spec, the following category exists on the XDI TC wiki:


This spec will define optional and mandatory security mechanisms. Peter gave a few examples of topics that could be covered by the spec:

Based on these mechanisms defined by the XDI TC, concrete (commercial) XDI services could profile them and add additional functionality, such as trust management.

Peter also pointed out the importance of conformance profiles, which the XDI TC will also produce to e.g. specify “minimal conformance requirements” for XDI servers.


The decision queue stack is shown on the following three auto-generated Category pages:




See also this list of proposals that need to be developed:



The next call is next week at the regular time.

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