Re: httpRange-14 Change Proposal

On 3/28/12 5:23 PM, Nathan wrote:
> Jeni,
>
> 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>" triple.
>
> 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:
>>> <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. 
>
> 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 
> format).
>
> 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 :SpaceShuttle.
>
> Can the TAG really just say "okay, all http:// URIs no longer refer to 
> anything"?
>
>> 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 
>>>> 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.
>
> 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.
>
> Nathan
>
>

+10000....

-- 

Regards,

Kingsley Idehen 
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen