W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: ISSUE-81 (resource vs representation)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 27 Sep 2009 20:57:31 +0200
Message-ID: <4ABFB59B.1030704@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Maciej Stachowiak <mjs@apple.com>, Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org" <public-html@w3.org>
Ian Hickson wrote:
> ...
>> It appears that you're saying that the phone number does not really 
>> identify a person then.
> It gives enough information to obtain a person. (Not enough information to 
> unambiguously obtain a _particular_ person.)
> ...

So phone numbers identify people (*), but not particular people? That 
doesn't sound like a helpful concept.

>> So then, if a resource is a bag-of-bits, what do you call the thing you 
>> address with a POST request?
> A POST request returns a bag of bits also, so "resource".

The response to a POST request is a bag of bits, but that doesn't *make* 
the resource a bag of bits.

>> It seems like it would be more painstakingly accurate to say "A URL is a 
>> string used to retrieve a resource" or "A URL is a string that provides 
>> the address of a resource." But even that is not quite accurate, because 
>> in the case of HTTP, it's the full HTTP request (including method and 
>> headers) that determines what resource you get, if you take resource to 
>> be the concrete octet sequence you get back.
> The sentence refers to _a_ concrete octet sequence, not _the_ concrete 
> octet sequence. It's not saying that the URL is enough to unambiguously 
> name a _particular_ resource, just that it gives enough information to 
> obtain _a_ resource.

That's consistent with your phone number example.

>> Technical purity is a *good* thing, unless it is in conflict with other 
>> design goals. I don't think it is in this case.
> It's in conflict with the design goal of using terminology that matches 
> what most people think of.

I disagree with that. Almost everybody who deals with resources is 
totally aware that the resource is an abstract concept, and, in the case 
of an HTTP resource, can be a static document, a Java servlet, a CGI 
script, whatnot; but certainly not the same thing as you get when you do 
a GET request.

> RFC2616's terminology is more abstract than is useful for most Web 
> developers, and therefore this kind of terminology confuses people. The 

Seriously, the only person confused here seem to be you.

The distinction of the abstract concept of a resource, and the thing a 
GET request returns (call it bag-of-bits, entity, representation, 
whatever) is present in *all* relevant specs (HTTP, URI, WEB-ARCH...).

> right thing to do here is to fix the HTTP spec's use of this terminology 
> to be more in line with what developers at large use. This is in fact 
> basically the same problem as with the term "URL" -- we should update the 
> specs that invent these new terms to use the terms people are familiar 
> with, so that the specs become more accessible to more people.

Ok then, so please answer the question I asked before: if the "resource" 
is a bag-of-bits, what is the thing you send a POST request to? It's 
certainly something else, so what's your technical term for it?

BR, Julian

PS: is a resource in the "tel" URI scheme a bag-of-bits as well? Is a 
"websocket" resource a bag-of-bits?
Received on Sunday, 27 September 2009 18:58:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:51 UTC