Re: fragment identifiers

At 02:20 AM 2002-07-23, Graham Klyne wrote:

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

In HTML and XML a #fragment sub-reference resolves to an element, a subtree
within the part/whole tree.

Roy did not discuss a #fragment referring to an arbitrary view.  Only to the 
elaborated form of a sub-object.  In fact the level of elaboration is independent
of the subtree identification, and is governed by browser settings as to whether
to expand images or not.


>[...]
>
>>[...]  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?

Practice is divided.  There is some of each.

The editors of various W3C documents have purged enumerals from their
anchor IDs and we managed to provide a lot of stability in the URI-references
into successive edits.

But this does not mean that I 


>[...]
>
>>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.

There may be evidence here that what RDF has done is intrinsically 
un-reconcilable with the bulk of incumbent practice and needs to be fixed.

The problem is that RDF as the referring language presumes that the cited resource
uses this specific #fragment value consistently, as a persistent sub-resource, contrary to what Roy's notes observe as being true of the semantics for a 
reference into anything but RDF.

Also, should some RDF be expressed in XML syntax, then an XML processor and an RDF processor will interpret #fragment indications in references into that resource differently, in conflict with the principle that Stuart is working on.  Consistency 
of sense.

The RDF semantics for #fragment works only if the referring document and the document referred to are both RDF.  This is not the level of interoperability that
is desired as "The Web."  Ergo, we need to fix something, and RDF, as the new boy
on the block, is probably the one that has to stand down.


>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?

Not in general.  See above.


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

Yes, basis for addressing, see above.

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

Roy's bit of history also captures the status quo of semantics as it applies to
a major corpus of usage on the Web today.  So in a sense, it provides us with
data for design-review virtual test cases on the interoperability of innovations
with the established base of practice.

In this way, you are right to experiment with extrapolations, but I fear the 
test fails to show interoperability.

Al

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

Received on Tuesday, 23 July 2002 11:31:42 UTC