Re: httpRange-14 Change Proposal

Nathan,

On 28 Mar 2012, at 16:07, Nathan wrote:
> Jeni Tennison wrote:
>> Yes, that's correct. With no constraining Accept headers, it could alternatively return HTML with embedded RDFa with a <link rel="describedby"> element, for example.
> 
> Is that universally true?
> 
> Suppose /uri identified a PDF formatted ebook, or a digital image of a monkey in JPEG format, or even an RDF document.

Then it would return those things. I think that you may have leapt to the conclusion that /uri *always* returns the same as /uri-documentation. There's nothing to my knowledge that says that, indeed given that you can have several :describedby links it would be impossible.

> Question A:
> 
> Currently we have:
> <http://example.org/uri> - a JPEG image of a monkey.
> 
> When you issue a GET on that URI the server currently responds
>  200 OK
>  Content-Type: image/jpeg
>  Link: <http://example.org/uri-documentation>; rel="describedby"
> 
> So under this new proposal, the server can return the contents of /uri-documentation with a status of 200 OK for a GET on /uri?

Under the proposal, the server would return the JPEG with a 200 OK for a GET on /uri. http://example.org/uri-documentation would return a description of the JPEG in some machine-readable format. 

> If yes, this seems like massively unexpected functionality, like a proposal to treat "Accept: some/meta-data" like a DESCRIBE verb, and seems to exaggerate the URI substitution problem (as in /uri would be taking as naming the representation of /uri-documentation).
> 
> If no, where's the language which precludes this? (and how would that language go, given that it's exactly the same protocol flow and nothing has changed - other than the reader presuming that /uri now identifies something that does have a representation that can be transferred over HTTP vs identifying something that doesn't have a representation that can be transferred over HTTP).

I don't really understand what you think it needs to say I'm afraid.

> Question B:
> 
> How would conneg work, and what would the presence of a Content-Location response header mean? Would HTTPBis need to be updated?

I can't see any way in which any of that would work differently from currently.

> Question C:
> 
> Currently 303 "indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP", and the Link header makes it clear that you are dealing with two different things (/uri and /uri-documentation), but where does this proposal make it clear at transfer protocol level that the representation included in the http response is a representation of another resource which describes the requested resource (rather than it being as the spec defines "a representation of the target resource")?

The proposal says that applications can draw no conclusions from information at the transfer protocol level about /uri. In particular, it can't tell whether the representation that is returned with /uri is *the content* of /uri or *the description* of /uri. Further information about /uri (eg that it is a foaf:Person) may help the application work out that the representation was *a description*.

However, an application can draw conclusions about /uri-documentation, assuming it gives a 2XX response, because it has been retrieved as the result of following a :describedby link (or if it were the target of a 303 redirection). The application can tell that the representation from /uri-documentation is *the content* of /uri-documentation and *the description* of /uri.

>> Either way, there is no implication that what you've got from http://example.org/uri is the content of http://example.org/uri (or that http://example.org/uri identifies an information resource), but there is an implication that what you get from http://example.org/uri-documentation is the content of http://example.org/uri-documentation (and that http://example.org/uri-documentation is an information resource).
> 
> Sorry I don't follow, how is there an implication from a 200 OK for <uri-a> that it's not an IR and for <uri-b> that it is an IR?

Because /uri-documentation was reached through a :describedby link. This extra information allows the application to draw the conclusion that the representation from /uri-documentation is *the content* of /uri-documentation.

> If there was a Set of all Things (Set-A), then that set would have two sets, "the set of all things which can be transferred via a transfer protocol like HTTP" (Set-B), and then everything else (Set-C) which comprises Set-A minus Set-B. As far as I can tell, the one thing that determines whether something is a member of the Set-B or Set-C, for HTTP, is that 200 OK in response to a GET, hence why we need the 303.
> 
> This proposal appears to try and override that "rule" (fact) by saying let the content of a representation define what is a member of Set-B or Set-C, however the act of dereferencing itself is what determines whether an identified thing is a member of Set-B, as Set-B is the set of all things that can be dereferenced. Hence my confusion at this proposal.


The "fact" that a 200 OK determines whether something is a member of Set-A or Set-B is a design choice made by httpRange-14, not a fundamental truth of the universe. The proposal makes a different design choice, in saying that you need more than just a 200 OK response to say, beyond all doubt, that a URI refers to something that is member of Set-B.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 28 March 2012 16:13:21 UTC