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

Re: temporal URI fragments (was: URIBOF at IETF meeting S.F.)

From: Paul Prescod <paul@prescod.net>
Date: Thu, 20 Mar 2003 22:37:41 -0800
Message-ID: <3E7AB335.6070400@prescod.net>
To: Silvia.Pfeiffer@csiro.au
CC: asgilman@iamdigex.net, uri@w3.org, Conrad.Parker@csiro.au, ozone@algorithm.com.au

Silvia.Pfeiffer@csiro.au wrote:
> ...
> 1) With the temporal offsets we are not querying any databases nor are 
> we composing a previously non-existent Web resource. All we are doing is 
> addressing a subpart of a Web resource. 

The subpart is a resource. You want the client to address it and the 
server to return a representation of it. To me, this is the definition 
of a resource.

> ... It is my understanding that that 
> was the original intention of creating the fragment component and 
> therefore we should make use of it.

The fragment component is something interpreted entirely on the client. 
That's why it doesn't generate a "new resource" the way the fragment 
identifier is perceived to.

> 2) Query results cannot be cached in network proxies, though Web 
> resources can.

Query results can be cached in network proxies. I believe this is a 
variant of the myth here:


The query result _does_ address a Web resource:


The HTTP 1.1 spec. is clear that query-retrieved entities CAN be cached, 
but you might have to trigger that explcitly:

    We note one exception to this rule: since some applications have
    traditionally used GETs and HEADs with query URLs (those containing a
    "?" in the rel_path part) to perform operations with significant side
    effects, caches MUST NOT treat responses to such URIs as fresh unless
    the server provides an explicit expiration time. This specifically
    means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
    be taken from a cache. See section 9.1.1 for related information.


If you look through the rest of that document you will see that query 
strings are accorded no special status except

> ... The use of fragments, which specify subparts of Web 
> resources, can enable the network to cache and reuse these subparts, 
> which provides scalability to the use of time-continuous data on the 
> Internet.

Caches will treat a fragment identifier on the wire as a bug, as they 
should. They will probably discard it.

> ...
> While this usage prescriptions may be appropriate for html pages, it is 
> not good for Web resources that consist of large volume data, of which 
> the user is only interested in receiving a small subpart. 

I believe your "large volume of data" is equivalent to what the specs 
mean when they talk about "database".

  Paul Prescod
Received on Friday, 21 March 2003 01:38:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC