- From: Larry Masinter <LMM@acm.org>
- Date: Sun, 18 Aug 2002 19:27:02 -0700
- To: <www-tag@w3.org>
In the good old days when we only used URIs for HREFs and other kinds of hyperlinking, it was safe to think of a URI as identifying some kind of communication endpoint (whether mailto:, telnet:, http:, ftp:, or the like), and to use the interpretation of a fragment identifier depended on the data type of the object retrieved. After all, RFC 2396 is pretty clear When a URI reference is used to perform a retrieval action on the identified resource, 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. fragment = *uric 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. ... That's why fragment identifiers can work with http: and ftp: but not with mailto: and telnet:, since the latter two don't support 'retrieval'. Now, URIs and URI references have been pressed into service to perform the function of identification, not only of the communication endpoint or a fragment of the result of a retrieval action, but also (through namespace names and RDF) as identifiers for abstractions. I think this is OK merely through reference: the resource vs. the abstraction for which it stands. But I don't like throwing out the definition in section 4.1 of RFC 2396 of fragment identifiers, and trying to make fragments identify resources instead of what that section says. Larry -- http://larry.masinter.net
Received on Sunday, 18 August 2002 22:27:24 UTC