Re: Content Sniffing impact on HTTPbis - #155

Ian Hickson wrote:
> ...
>> *You* may not need that distinction. However, when writing a spec, you 
>> aren't doing it for yourself, but for an audience of readers.
> 
> It is precisely this audience of readers who are most likely to benefit 
> from specs using concrete, understandable, and familiar terms like 
> "resource" rather than theoretical, abstract, and confusing terms like 
> "resource representation". There really is no reason to refer to an 
> abstract concept here. There is an identifier, there is a server, there is 
> an actual resource (by the dictionary definition, not the "newspeak" 
> definition used in the HTTP spec). Why introduce another term? What else 
> is there to refer to?
> ...

Under your "definition", the resource is selected based on *both* the 
URI and the context of the GET request (request headers, point in time). 
It's *possible* to explain things that way, but it is totally confusing 
because the *URI* is supposed to be the identifier, by definition. So it 
seems to me you're creating more confusion, not less.

> When you tell your command-line tool to fetch http://google.com/, it 
> returns an actual sequence of bytes form a server. It doesn't obtain a 

Yes. Plus metadata.

> representation of something, it just gets a thing. There's no nebulous 
> "resource" here, just a concrete set of bytes (which will vary based on 
> many things, such as cookies, IP, headers, etc).

Yes, it does get you a sequence of octets (entity body) plus metadata. 
"We" call it "representation of the resource", you call it "resource".

>> Changing terminology at this point is only going to cause confusion.
> 
> It is the HTTP and URI specifications that are, IMHO, continuing to cause 
> confusion by insisting on unfamiliar terminology.

Unfamiliar to whom?

Certainly not the W3C, see <http://www.w3.org/TR/webarch/#dereference-uri>.

But again; this discussion is pointless in that the inconsistency of 
terminology will be raised in Last Call, and then will have to change 
anyway.

BR, Julian

Received on Sunday, 14 June 2009 07:52:43 UTC