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: Deliverables and Informal Collaboration Teams


XDI TC Members and Observers,

I have (finally) posted the following notes about our V1 deliverables and
the informal collaboration teams that TC members volunteered for at the F2F
(and further discussed on the last call).

They are appended below and posted as a wiki page on the XRI/XDI wiki at:

	http://xrixdi.idcommons.net/moin.cgi/XdiTc_2fCollaborationTeams

We will review this again as an agenda item on tonight's call (the agenda
for which is coming out next).

=Drummond 

**************

= XDI V1 Collaboration Teams =

== Introduction ==
This page maintains a roster of the informal collaboration teams that are
finishing design and starting Working Drafts of the deliverables for the XDI
V1 specifications. The goal is to have an initial set of Working Drafts by
the end of Q3, 2005.

== Deliverable #1 - XDI Schema and Addressing V1 (Ajay, Bill, Paul,
Drummond) ==
This deliverable will specify the XDI graph model, the XDI schema used to
serialize the graph, and the rules for addressing XDI resources in the model
using XRIs.

=== Graph Model (3D Information Space) ===
 1. Formalized Data Model (Ajay and Bill)
 1. Refs and validation of equivalence assertions (Ajay and Nat?)
 1. Meta-model mappings (Andy and Paul)

=== Schema Definition ===
 1. RelaxNG (Bill)
 1. XML Schema (Andy)

=== XDI Addressing V1 (Drummond) ===
 1. Addressing Rules
 1. Return Value Rules

== Deliverable #2 - XDI Protocol V1 (Peter, Steve, Andy, Bill) ==
This deliverable will specify the XDI protocol in terms of the set of
abstract operations it supports and how these are bound to specific
transport protocols.

=== Abstract Operations ($op Space) ===
This section will specify the abstract protocol operations. The current
proposal is that these are rooted on the service dictionary XRI "$op".
 1. $op - the root XDI "verb".
 1. $op*get - operations that read the XDI graph but do not directly change
its state.
 1. $op*set - operations that write to the XDI graph and thus change its
state.

=== XDI Protocol Bindings ===
 1. HTTP
 1. SOAP
 1. BEEP

=== XDI Profiles ===
Profiles are for specific types of interactions with specific type of XRI
authorities, such as with an XRI registry, an authentication authority, a
data authority, etc. Bindings talk about physical, on-the-wire messaging,
whereas profiles talk about what is/isn't needed for specific types of
transactions - security tokens, contract requirements, data requirements,
etc.

''An open issue is how XDI profiles will intersect/overlap with XDI forms.''

=== XDI Security Mechanisms (Geoffrey and Peter) ===
This section will cover the mechanisms available for two XRI authorities to
develop a trusted communications channel.

== Deliverable #3 - XDI Service Dictionary V1 (Andy and Drummond) ==
This deliverable will specify the entries in the V1 service dictionary - the
"bootstrap vocabulary" of universally understood XDI resources that are used
to define the control vocabulary for the XDI protocol.

=== XDI Datatype Definitions ===
The current proposal is to base the default metamodel on the OASIS RelaxNG
schema language.

=== XDI Link Contracts ===
 1. Contract Definition
 1. Policy Definition
 1. Synchronization Definition

=== XDI Forms ===
''This is currently an open issue.''

=== XRI Addressing Reification ===
This is a set of service dictionary entries used to specify graph selection
operations (similar to, or perhaps based on, XPath).







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