Re: Generic-Resources-53: URIs for representations

Patrick Stickler writes:

> (b) if is known (by extra-web means) that a given URI denotes a 
> representation, then the agent is licensed to expect that every time
> it dereferences that URI it will get the same exact byte sequence

Yes, if you really mean "that" representation, but I think we're glossing 
over an ambiguity.

Consider one of my favorite examples, which is a clock resource.  The 
clock updates in real time, and representations of it change accordingly. 
For this example, assume that the clock resource at supports content negotiation.  It returns the 
representation of the clock as your choice of text/plain, in which case 
you get back the date and time as text, or image/jpeg, in which case you 
get the image of a round analog clock showing the current time.

Your analysis seems to apply to the case where we want a URI for the 
particular resource returned at, say 3PM, and I think your analysis is 
coherent for that case.  I don't think it's the main case of interest. 
What I think we're mostly considering is more along the lines of two 
additional resources which might be named:

These would not in fact return the same representation on successive 
accesses, but would invariably return representations using the particular 
media types.  I also think this is an appropriate use of URIs for 
representations.  So, I don't think that in all useful cases "URI denotes 
representation" implies "denoted representation octet stream is 
invariant".  I think the two URIs above denote representations of the 
original clock resource if the authority at says they do.

Also, I think I'm right that the term "representation" is appropriately 
applied not just to the octet sequence returned, but to some of the 
associated control data such as Content-type that's typically carried in 
some of the returned HTTP headers.


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Received on Saturday, 7 October 2006 03:05:39 UTC