- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 28 Dec 2006 17:48:47 +0100
- To: John Black <JohnBlack@kashori.com>
- Cc: "Sandro Hawke" <sandro@w3.org>, "Joshua Tauberer" <jt@occams.info>, <semantic-web@w3.org>
John, In defense of the current web architecture: On 28 Dec 2006, at 14:36, John Black wrote: > Tracing back through the steps that led me here, one major > user problem I am trying to solve is to avoid programming my > web server to return different http responses based on how I > classify the referent of my URI names. There is an existing solution to this problem for those who don't like httpRange-14, it requires no web server configuration, is theoretically sound, is widely deployed, and quite universally accepted: hash URIs. > I agree with Pat Hayes, the editor of RDF Semantics [1], > who said of the http-range-14 solution in his > presentation at IRW2006 [2], "In Defense of Ambiguity": Well, it's kind of hard to argue with what Pat said on that infamous slide, because it is quite disconnected from the rest of his presentation, and some of the statements are presented without any justification, and it's hard to know how he comes to his conclusions. (But the rest of the presentation is great and contains some of the most insightful stuff I've read on the subject.) So, Pat said: > [...snip...] > It uses a distinction in how a text is delivered (an http code) to > disambiguate the text itself; a category mistake analogous to > requiring the postman dance a jig when delivering an official > letter. Since the text bears no trace of its delivery, no > disambiguation is achieved by this." [3] I would say that there is plenty of prior art on using HTTP status codes to disambiguate delivered texts. In fact, almost all HTTP status codes serve that purpose. Whenever your web browser receives a "500 Internal Server Error", for example, the postman does indeed dance a little jig to tell your browser that the text is just an error message, and not a representation of the requested resource. The error page doesn't bear any trace of it's delivery either. Pat doesn't really present an argument as to why this is supposed to be a problem. (I'm sure he has good and valid reasons for his criticism, he just chose not to present them. I'd love to hear him expand on that though.) To me it looks like the 303 solution fits nicely into the existing use of HTTP status codes. 200 OK -- Here's a representation of the requested resource 301 Moved -- A representation of the requested resource can be found over there 404 Not Found -- I don't have any representations of such a resource 500 Internal Server Error -- Something's broken, I can't serve a representation right now 303 See Other -- I won't give you a representation of that resource, but some information about it may be available over there > I came up with the following suggestions that I > hope further illustrate Pat's point about this being a category > mistake. > > 1. For distinguishing URI that refer to things that do not actually > exist, dead presidents, extinct species, and unicorns, for example, > first return a "404 Not Found" code, then if the client requests the > same URI within 0.5 seconds, return a document describing the > non-existent thing. > > 2. For URI that refer to things that are bad for you, such as > cigarettes and high fat foods, return a "403 Forbidden" code and > then if they repeat the request, a document about that thing. The examples are entertaining (May I suggest the addition of a "207 Sarcasm" status code to HTTP?), but are different from the httpRange-14 case in an important way: They do not deal with a distinction that is relevant to the problem at hand -- the transfer of representations of resources over a network. The "303 for non-information resources" practice deals with a question that *is* somewhat relevant to the problem: Can all the essential characteristics of this resource be encoded in a message that we can send over the network? Your suggested "404 for unicorns" practice deals with a question that is *not* relevant to the problem. For the problem of transferring resource representations over a network, unicorns are no different from horses. (Is the distinction between information resources and non-information resources *important* for the problem of transferring representations? That's another question altogether, and I'm not convinced either way. I'm just saying that the 303 distinction is in the problem domain, while your suggested distinctions are not, and therefore I feel they don't back up Pat's point.) And anyway it should be 410 for dead presidents, not 404. Please be precise in your jokes. ;-) Richard > 1. http://www.w3.org/TR/rdf-mt/ > 2. http://www.ibiblio.org/hhalpin/irw2006/ > 3. http://www.ibiblio.org/hhalpin/irw2006/presentations/ > HayesSlides.pdf > > > John Black > www.kashori.com > > >> >> -- Sandro >> >> >> > > > >
Received on Thursday, 28 December 2006 17:15:39 UTC