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: RE: [xdi] Re: Proposed XDI TC Charter Revision v1


Victor,

Good points and good passion. A few points:

1) Link contracts is one of the major sections of the XDI Service Dictionary
deliverable. You have a good point that it doesn't mention that explicitly.
I'll revise the charter draft to do this.

2) One of the hardest parts of link contracts is the data and policy
referencing mechanism. Using XRIs to reference these (persistently) is the
foundation of this mechanism. That's why we were laying the XDI schema
groundwork first (at least that's why I've made it a priority). I'm not
happier than anyone else about how long it's taken (and much of that time
has been due to the continuing focus some of us have had to give to
completion of the XRI 2.0 cycle, which is still not quite done), but with
our consensus on the v13 schema, that groundwork is in place. 

3) I *like* your idea that due to the real-world-implementation demand for
it, we should launch immediately into the practical job of
defining/publishing the link contract format so folks can begin using it for
anything they want (just like they can use XRIs or the XDI schema for
anything they want) before the rest of the work is done.

And we don't need to define an "XDID" format to do this. We've already got
the XDI schema. We just need to define how you express a link contract using
this schema and then let developers start using it and giving us feedback.

What do others think of making this a priority?

4) This actually reinforces the reason for updating our charter - so we can
start producing referenceable Working Drafts that get each of these
bite-sized chunks out there. I know it feels like just more "process
overhead" but let's get it done and out of the way so we can focus on the
Working Drafts.

=Drummond 


-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org] 
Sent: Tuesday, November 08, 2005 10:49 AM
To: 'XDI TC'
Subject: [xdi] Re: Proposed XDI TC Charter Revision v1

There is a real disconnect for me in the current proposed XDI charter. 
As an implementer, the most important part of XDI to me is the concept 
of "link contracts". These, as the proposed charter states, are to 
support features including those to "govern authorization, access 
control, usage control, synchronization, and rights management." 
However, the list of deliverables does not even mention link contracts!

What's more, the proposed charter says "As a data sharing service, XDI 
is intended to be very simple and generalized." The one example I have 
seen so far of an attempt to implement anything like XDI is, imho, 
anything but simple and generalized. What's more, it doesn't include 
any actual implementation of link contracts.

Link contracts are the one thing that I would need to try to do any 
useful implementation, even experimentally. I think that the lack of 
work and attention to this aspect has been a huge drag on progress. 
Therefore I would like to propose something rather radical -- that we 
stand our approach to XDI on its head, and start from the link 
contracts end, rather than the schema end. A link contract, in my 
conception, would look quite a bit like an XRID (perhaps an XDID?), and 
would gain from our recent experience with crafting an XRID spec that 
is simple enough that it may actually be useful to non-XRI 
technologies.

An XDID would be a (simple as possible, all elements optional) schema 
capable of describing authorization, access control, usage control, 
synchronization, and rights management. It would be returned in 
response to a data query, similar to the way an XRID is returned in 
response to an authority query. It would contain a section analogous to 
the <service> section of an XRID, but would instead be a 
<serialization> section, where the available data structures could be 
discovered. This would allow data in -any- XML format (and any other 
format really -- anything serializable) to be addressed with XRI and 
controlled with XDI.

If there is a demand for the uber-XML format that the XDI TC has been 
struggling with for two years, work on this could continue, but 
progress and implementation experience would not have to be held 
hostage to that ambitious undertaking.

=vg




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