W3C home > Mailing lists > Public > www-tag@w3.org > September 2007

RE: HTTP Endpoints and Resources

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Thu, 27 Sep 2007 23:21:45 -0400
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C2033BA3EC@tayexc19.americas.cpqcorp.net>
To: "Rhys Lewis" <rhys@volantis.com>, "Pat Hayes" <phayes@ihmc.us>
Cc: "Technical Architecture Group WG" <www-tag@w3.org>

Rhys,

I agree entirely with your analysis about 303 responses and HTTP
endpoints.  I am only concerned that the terminology that you are using
is likely to be confusing if you posit a thingie that responds with a
303 code for a URI.

In general, any locator can be treated as a name for the thing that it
locates.  Thus, in one sense a locator *denotes* the thing that it
locates.  Indeed, in the 200 case the URI *does* denote the thing that
it locates.  But in the 303 case we're telling the world that it
doesn't, in spite of the fact that the URI is a locator for that
thingie.  That's confusing, and that confusion occurs if you posit that
thingie that responds with 303 codes for the URI.

On the other hand, I think there is a lot of merit in viewing the 200
and 303 cases similarly in some sense, because from the server
administrator's perspective, there isn't a lot of difference between
serving a file with a .html or .rdf extension (sent with a 200 response)
and a file with a .asis extension[1] that is sent with a 303 response.

So I suppose if you do go down this route of defining a class of "HTTP
endpoints", which are the thingies that send 200 or 303 responses, then
you could define "information resource" as being the subclass of HTTP
endpoints that send 200 responses.


1. http://httpd.apache.org/docs/1.3/mod/mod_asis.html

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
 
Received on Friday, 28 September 2007 03:22:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:18 UTC