|From a W3C point of view they are separate URI.|
This changes nothing in native XRI resolution. This is only talking about how it looks when you interact with an HXRI proxy.
There is put or update for XRI never has been. That would be the domain of XDI.
XRI is public only and get only.
That being said at ooTao the XRI authority server is a XDI server that serves XRD documents. You can certainly edit them via XDI the XRD is just a part of the XRI authority's graph.
However most people serve XRD form file system documents.
The 303 redirect may or may not be to an XRDS it could be to a blog or anything else depending on the configuration of the XRDS.
The only real change being proposed is changing the 302 redirect to a 303 redirect and adding the link headers.
The real change is getting the URL folks to look at it differently.
On 7-Nov-08, at 9:33 AM, Barnhill, William [USA] wrote:
So John, if I understand you correctly you are saying that in this proposal an HTTP GET on
would return a 303 redirect to
By the W3C's 'Cooler URIs' reasoning aren't those the same URI?
But that is not my main concern. An HTTP redirect is not a POST, nor a PUT, but a GET. Wouldn't that mean that this proposal would only work for HTTP GETs and would force XRDS updating to be done in some other manner? I'd prefer a mechanism that allowed a more or less RESTful style of interacting with resolvers through a uniform interface. I've seen the uniform interface constraint applied to HTTP taken to mean HTTP PUT, GET, POST, DELETE as the respective CRUD operations. I personally prefer a different mapping that was articulated in a recent blog entry (http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/
Create = PUT iff you are sending the full content of the specified resource (URL). Create = POST if you are sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm. Retrieve = GET. Update = PUT iff you are updating the full content of the specified resource. Update = POST if you are requesting the server to update one or more subordinates of the specified resource. Delete = DELETE.
I want to be able to do PUTs,etc. to an XRI for a variety or reasons. With the redirect approach as proposed how would I do that?
From: John Bradley
Sent: Fri 11/7/2008 11:34 AM
To: Nick Nicholas
Cc: OASIS XRI TC
Subject: Re: [xri] Resolutions
Yes it is a slippery topic for the TAG in general.
I have had the most success with them describing it in terms of
All XRI bound to http are "Cool URI". In the proposal they will
always return 303 redirects to resources and never the resource
itself. They will contain link headers in a manner consistent with
Mark Nottingham's proposals for XRDS-Simple/XRD.
They can use accept headers to choose between a number of possible 303
redirects for different representations of the "thing" identified by
The difference between a "Cool URI" and a "Cooler XRI" is that via
sub schemes a shared semantic also exists like ARK.
This allows http://xri.net/=Drummond to descibe the same thing as https://xri.net/=Drummond
. They are separate URI and can be treated as such by applications.
However XRI aware semantic web apps can discover the eqivelency by
examining the meta data or via knowledge of the sub scheme.
We however do need locators for the actual meta data files. The
question is are these locators in the https: space as seperate URI
distinguished by query parameters.
We have been considering http://xri.net/=drummond/?_xrd_r=application/xrds+xml
to be a locator that returns a 200 response with a XRDS document.
I am interested in knowing if you see a problem with that?
On 6-Nov-08, at 11:50 PM, Nick Nicholas wrote:
> Having now caught up on the W3C TAG list discussions:
> You know this, but I'll restate the obvious. After reading the
> emails, particularly http://lists.w3.org/Archives/Public/www-tag/2008Oct/0104.html
> and follow up:
> People will keep assuming that because http://xri.net/=drummond can
> resolve to an XRDS, http://xri.net/=drummond is an identifier for an
> XRDS. Jonathan Rees clearly thought so.
> Do not allow this. And do not distinguish between http://xri.net/=drummond
> and http://xri.net/=drummond/?_xrd_r=application/xrds+xml , or
> http://*.xri.net/=drummond and http://thing-described-by.org/xri/=drummond
> . =drummond, and http://xri.net/=drummond, both identify Drummond
> the Abstract Thing (the human being, in fact; Abstract really means
> Not Necessarily Digital). http://xri.net/... is also a service that
> gets back a description of Drummond. http://xri.net/=drummond/?_xrd_r=application/xrds+xml
> is a more refined service call, to get a particular kind of
> But Neither Service Call Identifies Drummond. If we say they do,
> we're back at the mess we started with. That's the inherent problem
> in using an identifier, URI, which is intrinsically also a service
> call. All we can do with this is, always return 303s in XRI
> resolution calls ("what you are getting Is Not Drummond. It's a
> description of Drummond"). That doesn't change whether we specify
> XRDS as a parameter or not. And maybe, push the XRDS-Location header
> more in examples (if not implementations). Because that XRDS-
> Location URL *is* the identifier for the descriptor.
> Pointing to the equivalence of, say, HTTP HEAD http://thing-described-by.org/info:xri:=drummond
> and HTTP HEAD http://xri.net/=drummond might not be such a bad
> thing rhetorically: it makes more clear the distinction between
> resolution and identification, and that the XRI resolution binding
> is not a retrieval of a resource named in the URL --- just as thing-
> described-by.org is clearly not.
> Again, I know you know this, but it'll be a lot of work to make sure
> URL-heads get it too.
> Dr Nick Nicholas; Link Affiliates, email@example.com
> Melbourne skype:opoudjis http://www.opoudjis.net
> "Despite millions of dollars of research, death continues to be this
> nation's number one killer." --- Henry Gibson, Kentucky Fried
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: