Re: httpRange-14 Change Proposal


First, thanks for confirming - many responses in line from here:

Jeni Tennison wrote:
 > The server *can* return the same content from the /uri URI and from
 > the /uri-documentation URI, but it does not have to, and it wouldn't
 > be sensible to do so for an image. Your first question asked if the
 > server could return the same content, your second asked if it must.

Apologies for any confusion from my wording, however I did mean "can" 
rather than "must".

In a nutshell then, this proposal says that you can return a 200 OK for 
a GET request on any URI, but if you return "a representation of a 
description of the thing referred to by <uri>" rather than "a 
representation of the thing referred to by <uri>" then you should say it 
is so by including the special "<uri> :describedby <uri-documentation>" 

Additionally, rather than special casing this so that this rule let's a 
publisher override the default 200 OK return a representation of a 
resource, the proposal also aims to change web arch and the HTTP 
specification such that a 200 OK in response to a GET no longer returns 
a representation of the requested URI, rather it just returns a 
representation which you must consult to find out what it is.

That's quite a large change to the web / web arch / http.

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

Sorry no, not *always* just *always could* or *always can*. As in, it 
would be universally true that for any successful GET request you would 
receive a representation, and that representation may be a 
representation of the <target-uri>, or it may be a representation of 
<some-other-uri> which describes the target-uri.

>> Question A:
>> Currently we have:
>> <>; - 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: <>;; 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. would return a description of the JPEG in some machine-readable format. 

Or more accurately, the server MAY return the JPEG with a 200 OK for a 
GET on /uri, or it may return the same result as a successful GET on 
/uri-documentation (a description of the /uri in some machine readable 

Is this limited to machine readable format, why not human readable too?

It appears that if one can return text/turtle for a GET request on 
</foo>, where { </foo> a :Horse } then one should also be able to return 
an image/jpeg which visually describes the horse.

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

Okay, given the use-case of a GET on </uri> returning 200 OK, and the 
response containing a representation of </uri-documentation> in text/turtle:

What would the value of the Content-Location header be? /uri-documentation?

short version: this proposal would mean many sections of httpbis would 
need to be reworded and changed, as it conflicts to the point of saying 
the opposite.

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

Wow, so every URI no longer refers to anything unless it's explicitly 
stated in some RDF somewhere, and if one looks up <b> in a browser and 
sees a picture of a monkey, they are incorrect for saying it refers to a 
picture of a monkey if some RDF document somewhere describes <b> as a 

Can the TAG really just say "okay, all http:// URIs no longer refer to 

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

I can't see how it could tell that "the representation from 
/uri-documentation is *the content* of /uri-documentation and *the 
description* of /uri". Perhaps that it's *a* description of /uri, but 
certainly not that it's "the content of /uri-documentation", the 
proposal itself removes all notion of a representation being a 
representation of the current state of the requested uri.

if <a> is described by <b>, and <b> is described by <c>, then a GET on 
<a> can now return <b>, whilst a get on <b> can return <c>, and so 
forth, and if that :describedby triple is missing, or you don't get back 
RDF in some form, then you don't know what you retrieved or if the 
requested uri refers to it at all.

>>> Either way, there is no implication that what you've got from is the content of (or that identifies an information resource), but there is an implication that what you get from is the content of (and that 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.

and when you don't reach it via a ":describedby" link (as in 99.99% of 
cases on the web)? also see above, same points.

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

Apologies but I have to disagree completely here, I can say I'm a 
goldfish but I have the properties of a human and belong in the Set of 
Humans, no matter how much I say, I'm never going to be a goldfish - 
there's no design choice there, similarly if something a representation 
of something was retrieved via HTTP, then it belongs to the set of 
things which can have their representations retrieved via HTTP, that 
just is a fact, not a design decision.

Sorry this appears so negative, but... well the above hopefully 
explains, personally I see it as ripping the foundational constraints of 
the web/uris/http away to try and save an extra GET request in a few cases.


Received on Wednesday, 28 March 2012 21:23:49 UTC