- From: Rhys Lewis <rhys@volantis.com>
- Date: Fri, 28 Sep 2007 08:02:24 -0600 (MDT)
- To: "'Booth, David \(HP Software - Boston\)'" <dbooth@hp.com>, "'Pat Hayes'" <phayes@ihmc.us>
- Cc: "'Technical Architecture Group WG'" <www-tag@w3.org>
Hello David, thanks for your response. I think that I'm starting to sense some consensus. I believe that on this particular topic, you, Pat and I have said pretty much the same thing during the last round of postings. > 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. Actually, though I'd love to take any credit, I didn't actually posit this. It's in the HTTP spec. The thing that responds with a 303 is a resource, in the sense in which that term is defined in RFC2616[1] (and which I've labelled http:resources for the purposes of this thread). I note your comment on potential confusion, but I think that can be handled by defining denotation and access carefully, in sort of way that Pat distinguishes them. > > 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. > Quite so. And I think Pat has also said something similar. I was quite attracted to this notion because it positions traditional uses of the Web (documents, information resources etc.) a special case of a more general mechanism. Not only are information resources the subset of http:resources that return 200, they are also the subset where what is denoted is what is accessed. That worked for me anyway. Best wishes Rhys [1] http://www.w3.org/Protocols/rfc2616/rfc2616.html
Received on Friday, 28 September 2007 14:02:41 UTC