Re: fragment prose proposal

At 04:48 AM 2004-02-26, Graham Klyne wrote:
>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.

OK, the problem could be isolated to where Roy said "indirectly provided"
where in fact it is "indirectly identified."  "Provided" is a red herring
as it carefully says elsewhere that there is no 1:1 relationship between
the URI used to identify and the operations employed to recover a 
representation.

The whole point of identification on the Web is that the party imparting the
URI to the user can be different from the owner providing [i.e. publishing]
the resource.

The indirection is in the utterance of the party providing the reference,
not in the resource 'provision' by the owner.  It's indirection in the naming,
but there is no implication that there is any particular arm's length 
separation behind that.

>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).

I got the impression that this is true, and constructively so,
in the 'info' scheme.

Can you explain why they shouldn't be doing what they are doing?

How is it '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.)

If you can't say it without 'client side' you are not solving the
problem.  Processing can be distributed across multiple nodes in
creative new ways that make the 'client side' undefined.

It has to be tied to the recovery operation, not client/server.

Interpretation of the prefix and suffix separated by '#' are separated
by the resource-recovery operation.  In the HTML case.

'Here' and 'there' are extraneous to the essential facts.

How do you want it to work in RDF for #fragment-bearing URIs for which
the 'primary resource' is not recoverable into any representation?

Opaque comparison of such URIs is supported?  Anything else?

Al

>#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 16:41:45 UTC