- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 25 Feb 2004 09:48:12 -0500
- To: uri@w3.org
<from> <quote cite= "http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment"> 3.5 Fragment The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. fragment = *( pchar / "/" / "?" ) The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. Individual media types may define their own restrictions on, or structure within, the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the retrieval request (a.k.a., content negotiation), then whatever is identified by the fragment should be consistent across all of those representations: each representation should either define the fragment such that it corresponds to the same secondary resource, regardless of how it is represented, or the fragment should be left undefined by the representation (i.e., not found). As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place. A URI with a fragment identifier may be used to refer to the secondary resource without any implication that the primary resource is accessible or will ever be accessed. Fragment identifiers have a special role in information systems as the primary form of client-side indirect referencing, allowing an author to specifically identify those aspects of an existing resource that are only indirectly provided by the resource owner. As such, interpretation of the fragment identifier during a retrieval action is performed solely by the user agent; the fragment identifier is not passed to other systems during the process of retrieval. Although this is often perceived to be a loss of information, particularly in regards to accurate redirection of references as content moves over time, it also serves to prevent information providers from denying reference authors the right to selectively refer to information within a resource. </quote> </from> <to> 3.5 Fragment A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. fragment = *( pchar / "/" / "?" ) The fragment identifier component of a URI allows identification of something, call it a secondary resource, by indirect reference in a context established by the resource identified by the rest of the URI (preceding the #fragment component). The secondary resource so identified may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A fragment's interpretation is in many schemes allowed to depend on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. Individual media types may define their own restrictions on, or structure within, the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. URI schemes may also define rules for fragments that their resources must follow. If the primary resource has multiple representations, whatever is identified by the fragment should be consistent across all of those representations. Operations on the URI including the #fragment component as an opaque object should be valid independent of recovery or non-recovery. When a resource is available in different media types, the interpretation of the #fragment should be consistent for those types supporting a #fragment interpretation. As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place. A URI with a fragment identifier may be used to refer to the secondary resource without any implication that the primary resource is accessible or will ever be accessed. However, if a retrieval is possible, a User Agent must be able to retrieve the resource using the URI preceding the #fragment component and interpret the #fragment in the context of the representation received for that resource. This must be without loss of information. Thus a User Agent may always strip and retain the #fragment component and apply it locally after retrieving a resource. For some retrieval mechanisms such as the HTTP protocol, the User Agent should generally strip the #fragment and apply it locally, as some server implementations may not process the URI correctly with the #fragment component retained. </to> <discussion> [why some sort of change is needed] I was particularly set off down this track when Martin started a quote with the following paragraph-head. <quote> Fragment identifiers have a special role in information systems as the primary form of client-side indirect referencing, allowing an author to specifically identify those aspects of an existing resource that are only indirectly provided by the resource owner. </quote> In the context of the preceding paragraph it is clear what Roy was thinking this should mean, but taken at face value this language is contrary to fact in at least three ways. Where it comes to _providing_ the information 'indirectly,' the leading technique on the web is by placing hyperlinks in the resource representations, and the second dominant method is via schemas and specifications to which representations claim conformity either by their message metadata or internally. In the common use of #fragment to point at an element in an HTML document, the 'secondary resource' is 'provided' *more directly* than the 'primary resource.' It is only the *identification* of the resource that is more indirect. The URI that the user is processing is not an utterance of the resource owner/provider, but of some third party citing the resource. The step is to localize to something you have already been given. The 'provision' of the 'primary resource' is more indirect than that, requiring a not-tightly-specified implementation of resource recovery. So we do need some different language in here to state what is going on and what should be going on. Please consider the above rewrite as leaving less room for misunderstanding. </discussion> Al
Received on Wednesday, 25 February 2004 09:53:04 UTC