fragment prose proposal

<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