Re: fragment identifiers

At 07:27 PM 7/22/02 -0700, Roy T. Fielding wrote:
>Document means a lot of different things to different people,
>one of which is a bag of bits representing the framework for a
>renderable page.  All uses of the term "document" in RFC 2396
>refer to the virtual document described by the retrieved
>representation of a resource, where the virtual document may
>consist of multiple individual representations within a single
>rendering framework (e.g., a web page may consist of HTML,
>stylesheets, in-line images, etc.).  In HTML, a fragment
>identifies a portion of the complete virtual document, not
>just the bits within the HTML framework.

Interesting point.  (Obvious enough with hindsight, but interesting to see 
it explicitly called out.)

I read that as saying that the idea is well established that a "view" 
selected by a fragment identifier is not necessarily contained within the 
resource representation to which it is applied.

[...]

>[...]  The fragment identifier will, if the resource
>provider has done it right, identify the same thing across multiple
>representations.

Well, yes:  that's a big "if".  As an ideal, that's fine, but is it truly a 
reflection of web architecture as practised?

[...]

>The aspect of fragments that is media-type-specific is the mechanism
>of the indirect reference when it is dereferenced.  The mechanism is
>not known (and cannot be known) until a representation is in hand.
>That is, either the fragment identifier is used in a same-document
>reference or an action equivalent to GET is performed on the URI
>preceding the fragment in order to obtain that representation.
>The representation, once in hand, determines what needs to be done
>to complete the retrieval action.

I think this is all fine as far as it goes, but I think it leaves untouched 
an aspect of fragment identifiers that's been nagging at a few of us who 
work with RDF.  (Maybe RDF's use of fragment identifiers is broken - as has 
been suggested in the past - and needs to be fixed?  I used to think so, 
but now think it can be reconciled with the Web usage you describe.)

So where's the problem here?  I find your description is centred very much 
around the actions of retrieval and rendering of a web resource 
representation.  RDF uses URI+fragment identifiers as opaque identifiers, 
without any presumption of retrieval and/or rendering.  There's nothing in 
your write-up that says how (other than "if the resource provider has done 
it right") a fragment identifier can be part of an identifier that denotes 
something independently of the form of representation that may be to hand.

So my questions to you are:

(a) do you recognize that (as for RDF) that a URI+fragment identifier can 
denote some value quite independently of resource representation?

(b) does your design rationale for fragment identifiers address this issue 
(or provide a basis for addressing it)?

Maybe I'm expecting too much here?  You did say that your message was to 
"describe some of the design history and rationale for fragment 
identifiers".  Certainly, against that criterion your message seems quite 
complete.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 23 July 2002 02:25:31 UTC