Re: temporal URI fragments

Silvia Pfeiffer (<mailto:Silvia.Pfeiffer@csiro.au>) wrote to
<mailto:uri@w3.org> on 7 April 2003 in "Re: temporal URI fragments (was:
URIBOF at IETF meeting S.F.)" (<mid:3E924D79.4080001@csiro.au>):

> In the Axioms of Web architecture - Fragments part
> http://www.w3.org/DesignIssues/Fragment.html it is stated that "When a
> document language (MIME type) has some form of intra-document naming for
> objects then it is intuitive if these names can be directly used as
> fragment identifiers." Many time-continuous Web resources have such
> named objects, e.g. QuickTime has chapter markers and Windows Media has
> marker objects. It would be intuitive to directly address them as
> fragments.

And it would be intuitive for anybody familiar with the development of URIs
that the fragment identifier means that the entire resource is passed and
available while only the identified fragment is emphasized or targetted.

> Time is such a property of time-continuous resources that
> also provides a structure that should be accessible directly through
> fragments.

I agree with this statement. I do not agree that the fragment identifier
should have an effect on what the server delivers.

> With both fragment types for time-continuous resources (named objects
> and timed offsets) we run into the problem of being forced to download
> the complete resource before being able to present to the user the
> expected subpart (or fragment). Understandably, fragments refering to
> anchors in html pages have been handled this way and the prescription to
> interprete the fragment component at the client side has come from this
> background.

I'll let Tim Berners-Lee, Roy Fielding, Larry Masinter, and Mark McCahill
answer on what influenced the specification of fragment identifiers. I
believe that the principles in effect are solid and good, regardless of the
motivation.

Let's take an example. Suppose that I have an enormous XML document, like an
aviation equipment specification. I might want to retrieve just a small part
of that document. Rather than pass a fragment identifier over the network
and expect the server to handle the fragment identifier, the Right Thing is
to append segments to the path to drill down through the document hierarchy.
So I integrate XPointer into the path, send the resulting URI to the server,
and get a few slim XML nodes in return. This scenario works just as well as
passing fragment identifiers for server-side interpretation, but does not
disturb existing semantics.

> This just does not fit with large-volume time-continuous
> data.

I agree. This means that fragment identifiers are inappropriate for handling
media extraction of the sort that you intend. Use parameters in the path
instead.

-- 
Etan Wexler <mailto:ewexler@stickdog.com>

Received on Tuesday, 8 April 2003 04:34:19 UTC