Re: [XRI] Back to XRI

David,

Having the meta-data at a known relative location to the "about-a- 
thing" URI is more practical where we have URI that all conform to the  
same rules through the proxy by say adding $XRDS to the path or query  
as an example.

It however prevents us from having a rule that all URI in a given  
space all of the URI are "about things" and not things themselves.    
This could be finessed if required.

A larger problem is for XRDS-Simple if the general rule is to add  
$XRDS to the path and there is no document at the location the client  
needs to go back to the original URI preform a HEAD or GET and  
retrieve the X-XRDS-Location header or Link header if we standardize  
on that.

A failure takes XRDS-Simple from 2 GETs to 3 GETs.

What would be ideal is if there was some equivalent to the Link Header  
for requests.

In my GET I would like to say
LINK:  rel="http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html 
"

I don't think that the ability to ask for an "information resource"  
that has a relation to a "non-information resource" is unreasonable.

I feel frustrated, in that responses have the ability if limited, to  
express relationships from "non-information resources" to information  
resources.

I want to say give me the XRDS information resource for the =jbradley  
"non-information resource".

I imagine that in response to such a request a Web Server might return:
1. The related document with Link Headers describing the relationship.
2. A link header describing where to find the related document and a  
303 to the related document or some other related document described  
in the Link headers.
3. A link header describing where to find the related document,  and  
some other HTML representation of the resource.

3 is a use case by Yahoo and others who never want to return the  
metadata from a URI that also delivers content.  This is due to the  
unpredictable behavior of proxies respecting vary.

As an example yahoo.com  returns content.  It is also the realm for  
describing the oAuth and other services Yahoo provides.

Because of there volume Yahoo, Google and others only want to serve  
the Link header describing where to find the XRDS for the realm to  
clients that specifically ask for it.

Someone must have brought up a similar use case before.  Asking for  
relationship information in a request is the obvious next step from  
supplying it in a response.

Perhaps I am missing something,  or my question is in some way  
heretical.  It certainly wouldn't be the first time.

Your input is appreciated.

Regards
John Bradley


On 12-Sep-08, at 12:46 PM, Booth, David (HP Software - Boston) wrote:

>> From: John Bradley [mailto:john.bradley@wingaa.com]
>> [ . . . ]
>> One of the things that we need the most work on is how to
>> perform what
>> might be thought of meta-data content negotiation for URI that are
>> about "things".
>>
>> The best solution we have found at this point is to use Link Headers
>> to indicate where the related meta-data can be found at distinct URI.
>> This is would be consistent with Mark Nottingham's draft
>> recommendations:
>> http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt
>> This clearly requires an extra GET that some users are resistant to.
>
> If the metadata can be in an arbitrary location then it does sound  
> like the extra GET may be unavoidable.  But if the metadata can  
> always be at a predictable location relative to the original URI,  
> and you can figure out a simple pattern matching rule to convert the  
> original URI to the metadata URI, then a smart agent could inspect  
> the first URI, determine that it uses the XRI http subscheme  
> convention, and use the pattern match to transform it into the  
> metadata URI without doing a GET on the original URI.  Would that be  
> a viable approach for you?
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not  
> necessarily represent the official views of HP unless explicitly so  
> stated.