On The Meaning of Fragment Identifiershttp://norman.walsh.name/2003/08/08/octothorp 6 69 2003-08-08 $Date: 2005-09-11 10:27:02 -0400 (Sun, 11 Sep 2005) $ Norman Walsh 2003 Norman Walsh Just what does the "#" in a URI mean? Franklin P. Adams I find that a great part of the information I have was acquired by looking up something and finding something else on the way. In response to my assertion about fragment identifiers:
[...] I think the assertion that a URI with a fragment identifier points to a dream or a car is absolutely unassailable. From a specification legalese point of view, that's rock solid.
several people have asked me what the heck I meant. Here's the scoop. Many of you are probably most familiar with fragment identifers used to point into HTML documents. For example, if you're reading the HTML version of this essay, the following URI points to the end of the page: The semantic of #name in HTML is that the browser finds an anchor named name in the document and displays the portion of the document that contains the anchor. There are two important, but possibly non-obvious, points in that description: The browser takes care of the fragment identifier. Servers never see fragment identifiers, they are handled entirely by the client application after it retrieves the URI without the fragment identifier. The text above describes the semantics of fragment identifiers in HTML. What a fragment identifier means is determined by the media type of the representation that you get when you retreive the resource. This comes straight from RFC 2396, the specification that describes URIs (the emphasis is mine):
[...] the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. [...] The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result.
So, to justify my assertion, I only have to find a specification for a media type that says a fragment identifier can refer to a dream. The Resource Description Framework (RDF): Concepts and Abstract Syntax document says just that. The RDF specification waves its hands a bit about the fact that the meaning of the fragment identifier is dependent on the media type, pointing out that if you can't get an RDF representation then [...] exactly what that view may be is somewhat undetermined, but that does not prevent use of RDF to say things about it.. You might think that's fairly soft ground, but I could not possibly comment. In any event, it strikes me as a significantly less thorny issue than httpRange-14. [This is the end of the page.]