Using the term "representation" bidirectionally [was Re: the mistake I made! ]

Sorry, I'm a little behind on these messages, but trying to catch up.
Comments below.

On Tue, 2011-03-01 at 08:01 -0500, Jonathan Rees wrote:
> On Tue, Mar 1, 2011 at 5:13 AM, Nathan <nathan@webr3.org> wrote:
[ . . . ]
> > Why reflects? well it's reflects because in the case of GET representations
> > can be conneg'd, subject to the capabilities of the agent, over language,
> > auth*, or media type or suchlike - hence "which are equivalent" - and in the
> > case of PUT, it's reflects because you may PUT a jpeg but the server will be
> > able to send back the same image in gif or png or a different size.

In HTTP-bis Roy is using the word "representation" both as something
that comes *from* a resource and as something that can be sent *to* a
resource (e.g., in a PUT request).  I first noticed this a few months
ago and it made me uncomfortable because I think it is easier to talk
about representations as things that you GET from (information)
resources, but not the other way around (PUT).  

We could use the term "representation" for both directions, as Roy is
doing in HTTP-bis.  But the difficulty I have with using it both ways is
that one direction (GET) is *far* more common than the other (PUT) --
especially in these discussions -- and the GET case is almost always the
one we're trying to discuss.  So if we use the same term for both
directions, then we either have to be sloppy or complicate our prose to
exclude the PUT case when we're really trying to talk about the GET
case.  

Thus, I personally think the discussion would be simpler if we reserved
the term "representation" to being *from* an IR (as with GET), and we
use a different term when the data is being sent in the opposite
direction.  I have not discussed this with Roy, but perhaps I should.


-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Friday, 4 March 2011 18:26:01 UTC