RE: [XRI] Back to XRI

Hello John, 

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of John Bradley
> Sent: 12 September 2008 21:42
> To: Booth, David (HP Software - Boston)
> Cc: elharo@metalab.unc.edu; www-tag@w3.org
> Subject: 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-V
> 2.0.html"

Hmmmm.... in RFC2068 the Link: header was defined as an entity header. HTTP GET request don't usually carry an entity body (I tried
scanning RFC2616 for a definitive statement and failed). So I'd expect a link: header really only to be present on an http response
message.

>From a web arch pov, a selector that is not visible in the request URI to distinguish between a data reference and metadata
reference is a bad thing (tm). That's only to say that distinct URI should be used to refer a thing and to metadata about that
thing. That's not to say that there should be any particular way of inspecting a given URI to determine whether it is a reference to
a 'thing' or metadata about a 'thing' (afterall metadata documents are 'things' too and may themselves have metadata about them).
  
> I don't think that the ability to ask for an "information 
> resource" that has a relation to a "non-information resource" 
> is unreasonable.

The link header mechanism is a way to set up a set of link relations that are reported in an http response. I think that I am open
to request headers (eg. accept) having an influence on what links a server responds with. However, in general an origin server is
unlikely 'understand' the 'intent' of a particular request - and so may not have a basis on which to restrict the set of links(if
any) that it responds with.

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

In your HXRI design you use extra parameters in your URI to that. I know that I have said to you that I would prefer and approach
that did not have to resort to parameter, but I don't have a better suggestion. At the very least they do distinguish the URI for
John Bradley from a URI for metadata about how to access services related to John Bradley (his email address, his IM channels...).

HEAD, rather than GET, is perhaps a very direct way of signalling an interest in metadata for a thing, rather than the thing itself
- but again would induce two round trips.

<snip />

> 
> 
> Your input is appreciated.
> 
> 
> Regards
> John Bradley

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England