- From: Roy T. Fielding <fielding@apache.org>
- Date: Tue, 19 Mar 2002 19:54:58 -0800
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- Cc: "'Jonathan Borden'" <jonathan@openhealth.org>, Paul Grosso <pgrosso@arbortext.com>, www-tag@w3.org, Chris Lilley <chris@w3.org>, "McBride, Brian" <bwm@hplb.hpl.hp.com>
Use of the fragment identifier as a means for constructing an artificial namespace is certainly possible, but isn't a reliable design. A fragment is a separate identifier -- a user-specifiable indirect identifier that allows identification of a portion of any representation, within the set of available representations, of a given resource. In other words, it allows a third party to identify the product of a retrieval action, or some portion of that product, indirectly via the resource URI. In general, that is something you want to avoid doing unless there is no other available means for directly identifying it as a resource with its own URI. You could say, within the limited scope of using a URI reference in a way that has nothing to do with identification of the current document, that a reference containing only a fragment identifier is intended to refer to the base URI. However, that doesn't help you face reality. Reality says that this protocol element will be implemented using the same relative URI parser as all of the other URI-reference elements, which means that reality will give you a result that differs from what you wanted. What is the point in defining a specification that doesn't produce interoperable results? The answer is that if you want a protocol element that is similar but not quite interoperable with the protocol element specified by the standard, then you cannot refer to that standard element. This is just basic common sense. The standard exists to help people achieve interoperable implementations, not to force people to implement all protocols using the same elements. ....Roy
Received on Tuesday, 19 March 2002 23:13:22 UTC