- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 26 Sep 2007 11:56:50 -0500
- To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
- Cc: "Rhys Lewis" <rhys@volantis.com>, "Technical Architecture Group WG" <www-tag@w3.org>
>Rhys, > >I like your recognition that 200 and 303 URIs have something in common, >but please don't refer to the 303 case has having an "http endpoint" >that "responds", because doing so would introduce the unnecessary >confusion of having the same URI denote two different things: an "http >endpoint" and the thing the URI was intended to denote -- a person, for >example. > No. This is confused because of the now venerable confusion, which continuously dogs all these discussions, between "identifying" in the sense of providing a functional Web-mediated connection to something, and referring to an object, aka denoting it. These are (forgive the shout) NOT THE SAME THING. Please don't get them confused. A name can denote without being attached (like all names off the Web) and it can be attached without denoting. This awful word "identifies" sometimes means one thing, sometimes another; but the two concepts are distinct. The fact that a URI provides access to something (a resource? I neither know nor care) which performs some meaningful action (such as a 303 redirect) does NOT imply that the URI, considered as a referring name, must therefore denote that thing (resource?). These two relationships, of accessing and naming, are COMPLETELY DISTINCT. Now, the TAG is suggesting, and I agree that this makes good sense, that *in the case where the accessed resource emits a 200 response* (and perhaps in similar cases for other xxTPs, i.e. where the access works 'normally'), then we should all agree that the accessing URI does indeed denote the resource: but this is a *convention* we are being asked to adopt, not a fact of nature or an architectural requirement. And this convention does not say ANYTHING about the relationship between denotation and access in other cases: nor should it, indeed, because there is nothing to be said in those cases. If you get a 404 error or if you get a 303 redirect, you can infer NOTHING AT ALL about what, if anything, the URI denotes. >What the 200 and 303 cases have in common is that the server's response >indicates that the URI owner has associated the URI with a resource, >i.e., the URI owner has "minted" or "allocated" the URI. (Slight >digression: hence the server's response can be viewed as "declaring"[3] >that URI.) But in both cases it is the *server* that sends back the >response -- not the URI. When the response is 200 we may colloquially >speak of "the URI responding", and this sloppiness in language is >harmless in that case because the URI denotes the resource that is >(conceptually) "responding". But when the URI denotes a person, and the >response is 303, it is *not* the person that is conceptually responding. >Hence, the sloppiness of talking about "the URI responding" becomes >quite misleading. But nobody said that the URI responded. In the 200 case, what responds is the resource Web-attached to, and denoted by (assuming the above-mentioned convention) the URI. In the 303 case, what initially responds is the thingie (resource?) which is Web-attached to the URI - which the URI accesses - but which (might but more probably) might not be denoted by it. In the 404 case, all bets are off. BTW, I don't think calling any of these a 'declaration' helps in any way at all, and if anything is only going to make things more confusing. Pat Hayes >3. URI declarations: http://dbooth.org/2007/uri-decl/ > > >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. > -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 26 September 2007 16:57:08 UTC