- From: Jonathan Rees <jar@creativecommons.org>
- Date: Fri, 6 Feb 2009 07:40:30 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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. 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. 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). 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. 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. Jonathan
Received on Friday, 6 February 2009 12:41:09 UTC