- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 19 Sep 2002 18:03:00 +0100
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: Tim Berners-Lee <timbl@w3.org>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, www-tag@w3.org
At 11:59 AM 9/19/02 +0100, Brian McBride wrote: >At 03:51 18/09/2002 +0100, Tim Berners-Lee wrote: > >[...] > >>* when used in an rdf document, someurl#frag means the thing that >>is indicated, according to the rules of the application/rdf+xml mime >>type as a "fragment" or "view" of the RDF document at someurl. > >As Martin Deurst has pointed out elsewhere, we also have to consider the >situation when RDF containing someurl#frag is embedded in another >document, e.g. HTML or SVG. The mime-type applicable to that document is >not application/rdf+xml and thus RDF has no authority to define what it means. The wording to which Tim alludes does not do that; i.e. does not attempt to impose a different interpretation on fragment identifier applied to the containing document. I think maybe a couple of scenarios are getting crossed over: a document may *contain* a URI reference with fragment identifier, and a document may be *referenced* by same. By my reading, the use of the mentioned document MIME type to determine the interpretation of a fragment id applies in the latter case. When RDF is embedded in some application/foo+xml, and that RDF contains a URIref with fragment identifier, it is not the containing document type that determines what representation of the resource to which the URIref fragment actually applies. Consider that one has content negotiation, and that a retrieval operation is performed using "accept: application/rdf+xml", with nothing else accepted. Then *if* one gets a response to such a retrieval request, one is entitled to expect that representation to be of type application/rdf+xml, and any fragment identifier will apply according to the rules of that MIME type. #g ------------------- Graham Klyne <GK@NineByNine.org>
Received on Thursday, 19 September 2002 12:58:27 UTC