Re: fragment prose proposal

On balance, I find I prefer Roy's wording, though you raise a plausible 
issue of possible confusion concerning "client-side indirect referencing" 
and the use of hyperlinks for indirect referencing.  I think "client-side 
indirect referencing" is intended to refer to something looser and broader 
than what is associated with a hyperlink.  I also note that Roy's phrasing 
is qualified with the phrase "identify those aspects of an *existing 
resource*" (my emphasis), which seems to exclude the hyperlink redirection.

In particular, I find that your phrase "... in a context established by the 
resource identified by ..." doesn't really add any new clarity to the issue.

I also think that "A fragment's interpretation is in many schemes allowed 
to depend on the media type [RFC2046] ..." is plain misleading, as it 
suggests that fragment interpretation is some how related to the URI scheme 
(which I think is wrong).

If this is really a problem, I suggest a much more modest change:
[[
    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.  ...
]]

to:
[[
    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 secondary aspects of an existing resource
    that are only indirectly provided by the resource owner.  ...
]]
(insertion of "secondary" before "aspects";  this is intended to echo 
earlier use of the term "secondary resource", and I think more clearly 
distinguishes from the case of using a hyperlink.)

#g
--

At 09:48 25/02/04 -0500, Al Gilman wrote:
><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

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Thursday, 26 February 2004 10:55:43 UTC