Re: PROPOSAL - i109: Clarify entity / representation / variant terminology

On 06/02/2009, at 11:40 PM, Jonathan Rees wrote:

> On Jul 28, 2008, at 9:49 AM, Mark Nottingham wrote:
>
>> I saw a number of +1's to this rough plan, and only Brian offering  
>> another path, which didn't seem to get much support.
>>
>> Let's try doing this (i.e., getting rid of variant -- remembering  
>> that there's a separate issue for 'requested variant' -- and change  
>> the definition of representation to be the same as that of entity,  
>> giving editors discretion to adjust instances of each as  
>> appropriate). We can revisit if necessary.
>
> (I'm sorry I'm coming late to this conversation and perhaps you have  
> discussed the following, but...)
>
> Yes, I could never understand the difference between 'variant' and  
> 'representation'.
>
> But I don't think making 'entity' and 'representation' synonyms  
> makes much sense. There are a couple of reasons.
>
> First, if they are synonyms, there is no reason to use both.
>
> Second, W3C (e.g. its web architecture recommendation, but the usage  
> has spread) reserves 'representation' to mean specifically an entity  
> in a 200 response.

Where?

That document defines it as:
> A representation is data that encodes information about resource  
> state. Representations do not necessarily describe the resource, or  
> portray a likeness of the resource, or represent the resource in  
> other senses of the word "represent".
>
> Representations of a resource may be sent or received using  
> interaction protocols. These protocols in turn determine the form in  
> which representations are conveyed on the Web. HTTP, for example,  
> provides for transmission of representations as octet streams typed  
> using Internet media types [RFC2046].
>
I see nowhere where it's bound to a 200 response. In fact, my browser  
doesn't find '200' in the status code sense once in that document.


> Thus an entity in a 404 response, or in a PUT or POST request, would  
> not be called a representation, but other entities wouldn't. There  
> is no reason to redefine 'representation' unnecessarily introducing  
> confusion with other specifications.

That's a discussion that's probably worth having. My understanding of  
Roy's position (I'm sure he'll correct anything I get wrong) is that a  
PUT response (for example) is a representation of *some* resource,  
it's just not the resource identified by the request-URI (unless it  
happens to have a matching Content-Location, of course). In that  
sense, it's representing the state of an anonymous resource.

Is this confusing? Potentially, but it is a consistent view of the  
world, which is something that we currently lack.


> Webarch goes further and says that a 'representation' is 'of' the  
> resource, meaning that there is a special relationship between the  
> entity and the resource -- it carries the information associated  
> with the resource's current state (in the REST sense), or something  
> like that (a different story for services).

Reference, please?

> This relationship doesn't hold for requests or non-200 responses.  
> This sort of makes sense because in the English language a  
> representation always represents something (is a representation of  
> something).  I'm not saying there is a reason for HTTPbis to make  
> such a commitment - that could be considered 'application layer',  
> and any theory of 'representation' could be left out of the protocol.

I'm not really sure what line you're trying to draw between HTTP and  
semantics, but I'm generally wary of such divisions. Perhaps I spent  
too much time around SOAP people...


> Fourth, the idea of 'representation' is useful because the protocol  
> doesn't make really sense without a little bit of (informative?)  
> explanation of the motivation for content negotiation. It is there  
> because there was an intended use case, namely translations  
> ('representations') of a document in alternative formats and  
> languages to meet user-agent preferences.

I don't see this as a strong motivation for keeping the difference in  
terms.


Cheers,


--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 6 February 2009 13:50:18 UTC