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