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: Agenda: XDI TC Telecon Friday 2012-04-06


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

Date:  Friday, 30 February 2012 USA
Time:  9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Bill Barnhill
Markus Sabadello
Joseph Boyle
Drummond Reed
Mike Schwartz

REGRETS

Giovanni Bartolomeo 

GUESTS

Cam Hunt
Kari Lippert


THE ETHERPAD LINK FOR TODAY IS:
     http://xdi.idearpad.com/59



1) IDTRUST BUDGET PROPOSAL

Markus has filled out the contract template and is waiting for a response from Dee.

Markus said he's fine with doing all the work, but also with having others working on it. Anyone else who is interested should contact Markus.

For hosting, we had a consensus to choose a cloud hosting provider. Markus will proceed with that.

Mike urged Markus to send any questions about the OX code that would be part of the project to the OX mailing list - that's the best place for support.

Markus said that as soon as the contract is ready and he begins, he'll email the list.


2) SPEC REPOSITORY REPORT

Bill reported that he is making good progress. He has an example Working Draft of the XDI Graph Patterns document in a DITA format. Bill choose this because it allows us to track changes to images as well as text.

The process is that we will be using Github. Everyone will using their own favorit Git client. For example, to create a new topic, you would do that in your own copy. Then you would create a pull request to the main Git repository. That request could then be discussed by the TC, and either accepted or rejected.

When accepted, the new branch would be pulled into the main branch and become part of the spec.

The three tasks that remain:
  1) Get the tool working fully.
  2) Produce a baseline version of the graph model.
  3) Produce an initial DITA set of files - one for each section.

Bill noted that part of the XDI documentation build he is working on includes specialized DITA topics. One such is 'capability', which I am renaming to 'feature'.  Sections of a 'feature' topic are


3) OPEN SOURCE PROJECT UPDATES

Mike showed a list of the test cases for different features that are supported in OpenXDI that he sent to the TC mailing list. He explained that they plan to create an automated testing tool for all these features. Initially it's an OX tool that will be run against the OX server, but it could be run anywhere.

Mike explained that each of the tests is backed by a set of XDI statements. This is extremely useful for illustration of each graph pattern.

Mike said that OX has also implemented supported for remote root nodes.

This brought up the question of whether we should a use cases document. Mike pointed to SCIM as an example of why a use cases document.

Markus reported that he didn't have any major new features to report for the XDI^2 library. He is experimenting with forming a network between 4 Freedom Boxes. It's configured as a distirbuted hash table maintaining a shared XDI graph. He is trying to put together a demo for IIW.

Drummond reported that he is working on the XDI documentation for several Respect Network scenarios and also preparing presentations to explain more about XDI to developers who will soon be joining the project.

Cam and Kari noted that All BitWorld work related to XDI and KRL will be posted here: http://github.com/BitWorld-us/Personal-Data. In addition they said that Bitworld plans to join OASIS so Cam and Kari can officially join the TC.


4) POSITIONING XDI

We discussed how we position "what XDI is". Mike felt that the closest "animal" to XDI is LDAP because it is both a protocol and a type of server.

Bill said that the way he communicates it is that XDI is: a) an API (with different bindings), and b) the graph model the API exposes.

We discussed the actual proposed XDI 1.0 spec modules at:

 http://wiki.oasis-open.org/xdi/XdiOneSpecs
 
 Bill and Cam spoke in favor of calling the main interaction spec "API". Drummond agreed.
 
 Mike has no objection to changing the name from "Messaging" to API if that helps market the standard to developers. Currently messages define the : FROM, TO, TIMESTAMP, LINK CONTRACT, TOKEN. I have had a lot of questions from people about how to perform XDI messaging via HTTP to OX, and perhaps this name change will help make that more clear.
 
 # DRUMMOND will update the name of that spec on the wiki page. (DONE)


5) PROPOSALS FOR BASELINE FOR WORKING DRAFT SPECS

Mike Schwartz has proposed to use the version of XDI Graph Patterns posted last June as the baseline for considering features for the Working Drafts. Drummond proposes to use the latest version of the XDI Graph Patterns he just posted:

   http://www.oasis-open.org/committees/download.php/45648/xdi-graph-patterns-2012-04-05.pdf
   http://www.oasis-open.org/committees/download.php/45649/xdi-graph-statements-2012-04-05.xlsx
   http://www.oasis-open.org/committees/download.php/45650/xdi-graph-statements-2012-04-05.pdf

Note that the Graph Statements document is now in Excel format so it is easier to parse programatically.

Also note that the semantics for multiplicity used in this version are documented at:

  http://wiki.oasis-open.org/xdi/XdiMultiplicity
  
In the short time we had to review the document, it was noted that the very simple initial diagram of the basic node and arc types was helpful but was no longer there.

# DRUMMMOND to add a page to the XDI Graph Patterns document with example simple graph diagrams.

Mike noted that these changes from Drummond need to be fully reviewed and agreed to by the TC.

Bill notes that the plan was to have two ballots: (1) an up-down vote on Mike's proposed baseline; (2) an up-down vote on Drummond's proposed baseline; members are asked to vote yes on only one.  The ballots however are not up yet, nor has membership been verified yet.

Bill stresses that any features going forward should be documented in a separate feature proposal for each feature, or very closely related features in a set, once we have established a baseline.  This is critical to get better forward movement.   See my note above on Feature topics.


5) RELATIVE XDI ADDRESSES

We need to discuss whether $words for XDI instances can be relative XDI addresses. Drummond noted that he removed the use of relative references from the current version of the XDI Graph Statements document.


6) NEXT CALL

The next call is next week at the regular time.






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