[go: up one dir, main page]

Re: Generic-Resources-53: URIs for representations

On Oct 6, 2006, at 22:05, ext noah_mendelsohn@us.ibm.com wrote:

> 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 this case, I'd argue that these URIs do not in fact denote  
Representations,
but rather resources which are tightly related to the clock resource,  
and
corresponding to particular "modes of view", and which share  
representations
with the clock resource -- such that at any given time, both the URI  
of the
clock and the URI of the mode of view may resolve to the exact same
representation, yet neither of those resources are themselves  
Representations.

It is perhaps a similar relationship as between a novel, and  
different editions
and/or translations of that work.

There are many different distinct ways to interact with a given  
clock, based on different
senses -- visually looking at the clock, listening to the chimes of  
the clock,
reading a written report of the state of the clock, even feeling the  
physcal location
of the hands of the clock (though not necessarily relevant to a web  
application),
and we may speak of all of those modes of view, or ways of  
interacting with the
state of the clock, without confusing the clock itself, or presuming  
that any of
those modes of view correspond to representations returned to a web  
client by
a web server.

While one cannot conclude that a given URI denotes a Representation  
because
it seems to always return the same octet stream, if any URI ever returns
different octet streams then one should be licensed to conclude that  
that
URI does *not* denote a Representation.

Many resources denoted by URIs can share the same set of  
representations.

One can have a URI denoting a clock and a URI denoting a picture of a
clock both resolve to the same octet stream, the same shared  
representation.

Just because two resources might share representations does not mean  
they are
the same resource, only that the URI owner chose to reuse the same octet
stream to represent the state of both resources, as he/she felt that was
sufficiently useful and correct. (one may disagree with a given URI  
owners
choice of representations, but that is entirely irrelevant to the  
architecture)

If in your example, the owner of the URIs and publisher of the  
representations
is aware that the representations are time specific and (presumably)  
generated
in some automated manner, and wants to provide unique URIs for the  
actual
representations, then that owner should choose URIs for the actual  
representations
which will always return the same octet stream. E.g. including
the time to some reasonable degree of precision:


    http://example.org/clock?rep=text&time=11:32:22
    http://example.org/clock?rep=image&time=11:32:22

which in this case would probably be sufficient URIs for those  
Representations
such that they would always resolve to the same octet stream  
consistent with
the maximal resolution of the particular mode of view.


> 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.

And I would conclude that, because the two URIs

         http://example.org/clock?rep=text
         http://example.org/clock?rep=image

do not always return the same octet stream, that they do not in fact
denote Representations and that if they should, then either your server
is not behaving properly or there is ambiguity (URI overloading)  
resulting
in inconsistent behavior.

>
> 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.

I don't think so.

A representation of course has descriptive metadata, and presumably  
all of the HTTP
headers in the response describe the representation, the octet  
stream, not the resource
denoted by the request URI.

However, regarding Content-type, note that a given representation, a  
given octet
stream may conform to multiple Content-type values that might be
definable for that octet stream.

So even with a given representation, which is always the same octet  
stream, one could
expect that with content negotiation where the server is confirming  
to the client that
it understood the requested content type by reporting the Content- 
type value
to be the same as specified in the request, yet due to the fact that  
the same
octet stream may correspond/conform to more than one content type/ 
encoding, that
the same representation (octet stream) may be served to multiple  
clients over time
with different Content-type values in the response header, yet still  
be the same
octet stream, the same representation.

Thus, a given representation, a given octet stream is not bound to  
one and only
one consistently reported Content-type value.

Eh?

Cheers,

Patrick



>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>

Received on Monday, 9 October 2006 14:13:19 UTC