[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]