- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 16 Nov 2006 02:16:50 +0100
- To: Xiaoshu Wang <wangxiao@musc.edu>
- Cc: "'Max Voelkel'" <voelkel@fzi.de>, "'Semantic Web'" <semantic-web@w3.org>
Xiaoshu, On 14 Nov 2006, at 22:18, Xiaoshu Wang wrote: >> From RFC 2854 [1]: >> >> | For documents labeled as text/html, the fragment identifier >> designates >> | the correspondingly named element; any element may be named >> with the >> | "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and MAP >> elements may >> | be named with a "name" attribute. >> >> So, the frag id names an *element*, a structural part of the >> document. >> >> This increases my conviction that, if #Bob is a person, a 303 >> should be done before we serve HTML. > > The semantics you refered is the semantics of text/html but not the > HTTP > protocol. As far as the HTTP protocol is concerned, the #Bob is never > requested. What is requested is the http://example.com/resource, > which is > an information resource. True. > How to interpret the semantics of #Bob is at the > client side and it is not coverred by the httpRange-14. It's not covered by httpRange-14, but by the URI spec. The URI spec says that the content type of the response to http://example.com/ resource determines what #Bob identifies. I don't think it makes sense to say that the semantics of #Bob is interpreted at the client side. By serving some content type, the naming authority at example.com communicates something about the meaning of #Bob. By serving HTML, it communicates that #Bob identifies a part of an HTML document. By serving a 303, it communicates nothing except what is said in the target document of the redirection. > If the agent > "thinks" it has requested the http://example.com/resource#Bob, then > it is > the wrong implementation of the agent that leads to the wrong > conclusion, > but not the httpRange-14 resolution, don't you think? The client has to request http://example.com/resource, but the response will tell something about #Bob. Richard > > Xiaoshu > >
Received on Thursday, 16 November 2006 05:17:05 UTC