RE: [xri] Resolutions

["Barnhill, William [USA]" <barnhill_william@bah.com>]

So John, if I understand you correctly you are saying that in this proposal an HTTP GET on

http://xri.net/=drummond

would return a 303 redirect to

http://xri.net/=drummond/?_xrd_r=application/xrds+xml

 

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?

Thanks,

=Bill.Barnhill

 

 

---

From: John Bradley
Sent: Fri 11/7/2008 11:34 AM
To: Nick Nicholas
Cc: OASIS XRI TC
Subject: Re: [xri] Resolutions

Thanks Nick,

Yes it is a slippery topic for the TAG in general.

I have had the most success with them describing it in terms of  
"Cooler XRI"

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 XRI.

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?

John Bradley
=jbradley

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  
> description.
>
> 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,      opoudjis@optushome.com.au
> 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  
> Movie.
> __________________________________________________________________________
>
>
>
>
>
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php