- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Wed, 6 Sep 2006 15:47:59 -0400
- To: "Dan Connolly" <connolly@w3.org>
- Cc: <simonstl@simonstl.com>, <noah_mendelsohn@us.ibm.com>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, <www-tag@w3.org>, <www-xml-linking-comments@w3.org>, "Jonathan Marsh" <jmarsh@microsoft.com>
> From: Dan Connolly [mailto:connolly@w3.org] > > On Wed, 2006-09-06 at 13:59 -0400, Booth, David (HP Software - Boston) > wrote: > > . . . > > Protocol messages may be used in the process of determining > > the meaning, but there is a difference between the meaning > > being determined by the content of the retrieved message > > versus the mere fact of retrieval. In determining the meaning > > of http://simonstl.com/#news , if a GET on > > http://simonstl.com/ returns a 200 OK and an HTML document, the mere > > fact of retrieval indicates that http://simonstl.com/#news > > identifies a location within an HTML document. It therefore > > cannot, for example, identify a person or a dog. > > So don't publish an HTML document there if you want to use it > to identify a Dog. That was my point! Hash URIs are more restrictive than slash URIs with 303-redirects because the meaning of a hash URI depends on the media type. I.e., they are interdependent. Slash URIs with 303-redirects do not have this limitation: you can serve any media type *independent* of the kind of resource that you wish to identify. >From a design perspective, this difference is significant. If you are minting a new URI to identify something other than an "information resource"[], it doesn't make any logical sense to tie the meaning of that URI to the current media type of your documentation. At some point in the future, you may wish to serve your documentation using some new or different media types. (As the WebArch says, new media types are "a means by which the Web can grow"[2].) And as this thread has illustrated, the question of whether the meaning would remain "sufficiently consistent"[2] across media types is not at all obvious. [2] WebArch section 3.2.2 on Fragment identifiers and content negotiation: http://www.w3.org/TR/webarch/#frag-coneg David Booth
Received on Wednesday, 6 September 2006 19:49:00 UTC