W3C home > Mailing lists > Public > uri@w3.org > April 2003

Re: temporal fragments

From: Mike Dierken <mdierken@hotmail.com>
Date: Thu, 24 Apr 2003 22:19:01 -0700
To: <uri@w3.org>
Message-ID: <Law11-OE58MEI7lMnVM0000312f@hotmail.com>


----- Original Message -----
From: "Dave Singer" <singer@apple.com>
>
> I like Sylvia's idea and concepts, but I agree, I have to be able to
> know (client side) how to handle a URL before I even contact the
> server.
When you say 'handle a URL', do you mean you need to understand whether to
send a fragment identifier or not?
Or do you mean you are doing a retrieval of data identified by the URL and
you need to know how to handle the data returned?
If it is the first, then the URI specification says that the fragment
identifer is never sent to the server.

> Indeed, I need to know what I (client) will interpret
A piece of client software will always know what is capable of interpreting,
I would imagine.

> and what I want the server to handle.
Well, what you want and what you get are different things.

> It seems that the specification of how fragments are handled
> should be owned by the protocol (rtsp, http), not the MIME type, no?
What do you mean by 'fragment' - do you mean how the fragment identifer
portion of a URI is handled by a client? or do you mean a portion of the
data returned by a retrieval operation?

If by 'how fragments are handled' you mean 'how fragment identifiers in URI
are handled', then it is the URI specification that details that.

If you mean 'how portions of retrieved data are handled' then it would make
sense that the definition of that retrieved data specify how a fragment of
data is located and used.

For example, if a client wants to get the 5th paragraph of some text, the
client would do different things based on whether the returned data was
text/plain or text/html (or PDF, or MS-Word, etc.).
Received on Friday, 25 April 2003 01:24:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT