I would need to find it again, but if I remember right the proposed policy is that any TC member disagreeing strongly enough on a proposal should come up with
a documented counterproposal, which then is moved to highest priority. They have a week in which to do so, after the vote on the proposal is published.
FYI, I agree with Giovanni. I tried very hard to push for an HTTP binding that makes use of varied HTTP error codes, headers, one op per method request, different
method semantics, etc. I could not sway the rest of the TC. I think what we are creating is more of an HTTP payload than it is an HTTP binding, and I think it is a mistake, but I am in the minority opinion.
That said, I think it can be made to work, albeit with limitations. We will have problems with caching that we’ll need to create from scratch solutions for,
rather than re-use the HTTP caching, but we might have needed to do that anyway due to link contracts. We’ll need XDI methods for checking to see if a graph has changed, etc., rather than use HEAD and XDI extended headers, and so forth.
My number one goal is not to make the spec perfect at this point, but to make the spec flexible and extensible, so it can evolve, and make it the spec quickly.
My timeline requirement is a committee draft spec with all the necessary ingredients to implement a client or server, but choppy flow and lack of full editing, by September 1, and submission for ratification before the end of October.
That spec should answer four stories only, and that will be a push as it is as each story has several sub-stories:
1)
As an XDI developer, my software needs to establish authentication credentials (and know how to use them) for itself, and/or the user it represents
to the XDI endpoint for a graph with a given XRI, in order to create a sub-graph, add data in that graph, delete data in that graph, get the graph or a sub-graph represented by an XRI , or get the value addressed by an XRI
2)
As an XDI developer, given authentication credentials, my software needs to be able to securely use XDI messaging to create a sub-graph, add data
in that graph, delete data in that graph, get the graph or a sub-graph represented by an XRI , or get the value addressed by an XRI, in order to exchange data in an interoperable, secure, manner.
3)
As an XDI developer, I need to be able to enable, and revoke, sub-graph sharing with another entity (person or software), so that I can notify them
automatically when data changes, and be part of bi-directional data pipelines.
4)
As an XDI developer, I need to know the steps to writing and deploying an XDI data service, so that my data service is interoperable and can take
part in bi-directional data pipelines.
With some work the above could serve as the outline for the XDI 1.0 specification.
FWIW we did get consensus that other bindings are permitted for http. So if someone creates a REST-style HTTP binding then the developer attention economy
will choose between the bindings, and XDI 1.1 can recommend the one chosen – spec Darwinism at its finest.
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
1-443-924-0824|
barnhill_william@bah.com
From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org]
On Behalf Of Markus Sabadello
Sent: Tuesday, July 03, 2012 10:29 AM
To: Giovanni Bartolomeo
Cc: OASIS - XDI TC; Drummond Reed
Subject: [External] Re: [xdi] HttpXdiMessagingBinding
Hmm I think the idea behind not relying too deeply on specific HTTP features was that XDI should allow bindings to several different protocols, and should still always work kind of the same way.
Anyway, Bill what is the process if one TC member disagrees with a proposal?
He would have to write a counter-proposal, right? :)
Markus
On Tue, Jul 3, 2012 at 1:00 PM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:
Hello,
Whereas I like very much the idea of an HTTP binding for XDI (thanks Markus for having started this page), I have to express my concern on the choice of remaining formally compliant with it without really relying on its already provided semantics.
I would be in favour of a deeper integration, especially now that developers seem finally to have re-discovered (http://programmableweb.com) the unifying power of REST, that, as often Bill has pointed
out, is much more than CRUD.
I think we should take more advantages of functional (e.g., addressing, methods, error codes, eTags, etc.) and non functional (e.g., caching) capabilities already offered by the protocol, instead of duplicating this functions on top of it.
NOTE: I'm not saying that XDI should totally rely on HTTP. I'm saying that, where HTTP (or another protocol) already provides these functions, it would be a pity to replicate them on top of it, rather than proceed with a mapping.
Sorry to be once more not aligned with the position of the TC members :)
Thanks,
Giovanni
Def. Quota Drummond Reed <drummond.reed@xdi.org>:
Markus, good job on this. I added a sentence to the "Out of Scope" section
to clarify that the questions/issues listed there are out-of-scope for this
proposal but should be dealt with in other proposals.
Everything else looks good to me.
I encourage everyone else to review it -- unless there are any objections,
we will approve this proposal on this Friday's telecon.
=Drummond
On Sat, Jun 30, 2012 at 4:29 AM, Markus Sabadello
<markus.sabadello@xdi.org>wrote:
I updated this page according to what we talked about during the TC call,
please review.
https://wiki.oasis-open.org/xdi/HttpXdiMessagingBinding
Markus
----------------------------------------------------------------
Invito da parte dell'Ateneo:
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata
codice fiscale: 80213750583 http://5x1000.uniroma2.it
---------------------------------------------------------------------
To unsubscribe, e-mail:
xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
xdi-help@lists.oasis-open.org