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 http://example.org/clock 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: http://example.org/clock?rep=text http://example.org/clock?rep=image 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 example.org 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 -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------Received on Saturday, 7 October 2006 03:05:39 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 September 2008 07:02:12 GMT