W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

Re: fragment identifiers

From: Dan Connolly <connolly@w3.org>
Date: 25 Jul 2002 17:12:38 -0500
To: "Roy T. Fielding" <fielding@apache.org>
Cc: www-tag@w3.org
Message-Id: <1027635159.11000.821.camel@dirk>

On Mon, 2002-07-22 at 21:27, Roy T. Fielding wrote:
[... historical bits; I take no issue with these...]

> I'll restate my most recent thinking on the subject from a prior
> message to www-tag:
> Fragment identifiers are client-side indirect references, similar
> to how server-driven negotiation in HTTP allows a server-side
> indirect reference.  The fragment identifier will, if the resource
> provider has done it right, identify the same thing across multiple
> representations.  Even a resource mapping to static content will
> have multiple representations over time -- they will all be
> byte-equivalent, but not age-equivalent.  Thus, if the resource
> provider has done it right, a fragment identifier can be used to
> consistently define a "thing" similar to a resource.  We do not,
> however, call that "thing" a resource

I do.

> because it simply is not
> available on the WWW interface as a resource

Yes it is; I can refer to it in the WWW context,
and it's clear what I'm referring to.

> -- the WWW does not
> and never has treated the fragment identifier under the same rules
> of processing as the resource identifier, since doing so would
> interfere with the intent and result of client-side indirection.

Along those lines, I don't see a clear distinction
between http://example/#foo and mailto:foo@example.
i.e. what we expect clients to do with identifiers
has to do with more than just whether there's a # in there somewhere.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you in Montreal in August at Extreme Markup 2002?
Received on Thursday, 25 July 2002 18:12:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC