Re: fragment identifiers

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

Do you at least have some way of distinguishing between the two when
talking about architectural elements?  I agree that they are both
identifiers of things that can be useful, but there are many ways
in which the architecture can work with resources that it simply
cannot do so with fragments.  I need a distinction, so one side is
a resource and the other is an indirection.

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

It is available on the interface only as an indirect identifier.
That is a significant limitation -- just ask the people who work
on content management systems.  There is no way to dynamically
correct the reference of old or incorrect fragments because the
server cannot distinguish between requests of the resource with
or without an associated fragment.  It is therefore not a resource
from the perspective of WWW technology and it does no one any good
to confuse the two.

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

The #foo doesn't leave the client when performing an interaction
between components within the WWW architecture.  By definition,
information that stays within a component when performing an
interaction is not a data element for that interaction.  Since the
whole architecture is based on the premise of interacting with
resources that are identified by the data element of an interaction
request, it is not reasonable to label both as resources.

What people are capable of doing with identifiers is limited by the
technology that makes use of those identifiers.  There have been
several examples of proxy implementations of mailto that do hide
the distinction between "http://example/foo" and "mailto:foo@example".
Those implementations cannot do the same with "#foo".  When we talk
about the two in terms of architecture, it is appropriate that we
distinguish between resources and things that are only indirectly
accessible via resources, even if they are both resourceful.

....Roy

Received on Thursday, 25 July 2002 20:08:47 UTC