- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Thu, 4 Oct 2007 18:31:14 +0000
- To: Rhys Lewis <rhys@volantis.com>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- Cc: 'Pat Hayes' <phayes@ihmc.us>, 'Technical Architecture Group WG' <www-tag@w3.org>
Rhys, > From: Stuart Williams > > [ . . . ] > > So why add yet another term to an already confused and > > confusing space? Won't webarch:Resource or plain Thing (and > > webarch:InformationResource if you have to distinquish) serve > > in this case? I tend to agree with this sentiment. 1. I do not think it makes sense to posit the existence of an "HTTP endpoint" for a 303 resource without also doing so for a 404 resource, because a 404 can be returned in *exactly* the same way as a 303 or 200 is returned, such as from a .asis file, for example: http://dbooth.org/2007/funny404.html.asis Servers can be configured to return 200, 303, 404 or any other response by default or in response to specific URIs or ranges of URIs. 2. I do not see the rationale for grouping 200 and 303 responses in the same boat *unless* we say that these responses indicate that the URI owner has associated the URI with a resource. For the 200 response it is clear that the owner has. For the 303 response it is less clear, but there is some evidence: the server acknowledging the existence of the URI, instead of giving a 404. Thus, even though the 303 case cannot be guaranteed to indicate that the URI owner has created an association between the URI and a resource, I think it is architecturally reasonable to view it as though the owner has, while acknowledging that in some cases the resource may be incompletely characterized. (And in the extreme case, it may not have been characterized at all.) 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 Thursday, 4 October 2007 18:31:52 UTC