- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 27 Sep 2009 20:57:31 +0200
- 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