Using HTTP Headers to Request Descriptors (was RE: [XRI] Back to XRI)

John,

 

I changed the subject line because the approach you suggest for using an
HTTP Link header to explicitly request a description of a resource
("descriptor") seems particularly promising. "Finding Resource Descriptions"
[1] has many good references to discussions around this topic, but most of
them seem focused on how to return links to descriptors in HTTP responses,
not how to explicitly request them. Other resource descriptor formats like
POWDER [2] also seems to focus on Link headers in responses vs. requests.

 

What I like about putting this semantics in a request header is that it
could be explicitly defined to mean: "If possible, give me (or redirect me
to) a descriptor of the target resource that has this specified relationship
(rel= value) to the target resource." And if the value of the rel attribute
was a URI, then there would be no limit to the types of descriptors that
could be requested and potentially returned directly, without any extra
round trips and with very precise semantics.

 

In effect, it would be like the client explicitly asking the server for a
303, but being able to specify the precise type of related resource the
client is seeking, and for the server to actually return that resource
directly if it has the ability to do so. And because the semantics would be
explicit that the client is asking for a descriptor of the resource and not
the resource itself, it would get around the problem described near the end
of [1]:

 

            "If you ask for RDF, you get the description. If you ask for
something else, you get the thing described. (The TAG, TimBL, and others
have pointed out that this contradicts web architecture, which requires that
content negotiation choose among things that all carry the same information.
That goes for CN between RDF and HTML as much as it does for CN between GIF
and JPEG.)"

 

Do I understand this correctly?

 

=Drummond 

 

[1] http://esw.w3.org/topic/FindingResourceDescriptions

[2] http://www.w3.org/TR/powder-dr/ 

 

  _____  

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
John Bradley
Sent: Friday, September 12, 2008 1:42 PM
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-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.