Re: terminology question

Jacob Schroeder:
>
>Thank you (all) very much for answering so promptly!
>
>So it seems at least to be consesus, that the definition in the actual HTTP/1.1
>document is obsolete :( , but since the terms seem to be used consistently
>there, this does not much harm to the document itself.

I don't see how the 1.1 terms would be obsolete.  It is true that some
concepts needed when one is to extend HTTP are not defined as terms in
HTTP/1.1.

>On Tue, Apr 06, 1999 at 06:52:48AM -0700, Roy T. Fielding wrote:
>> Nope, that's backwards.  Each possible entity from a resource is
>> a "representation" of that resource at the time the message originated.

The best way to think of an entity, in my opinion, is to consider it
to be a _copy_ of a representation which was made at some time.  A
representation exists internally in a server.  An entity exists in a
HTTP response (or request).

>> A representation is a variant if, at origination time, the set of
>> possible representations has a membership greater than one.

No, this is not how the 1.1 spec defines it.  I would say that in 1.1,
'representation' and 'variant' are synonymous terms.  A cut-and-paste
of the definition:

   variant
      A resource may have one, or more than one, representation(s)
      associated with it at any given instant. Each of these
      representations is termed a `variant.' Use of the term `variant'
      does not necessarily imply that the resource is subject to
      content negotiation.

All this means that the term 'variant' is not very useful when
defining details of content negotiation.  Changing the meaning of
'variant' from the 1.1 definition, so that it signifies something more
specific than 'representation', is not the way to go.  Jeff defined a
term 'instance' to mean something more specific in his work, and I
defined another term 'variant resource' for transparent content
negotiation (rfc2295), also to mean something more specific.

[...]

>So the different possible entities produced by some CGI script (maybe
>including the remote IP address) would be termed "variant" as well, and this
>could be considered a special case of content negotiation? (I know this sounds
>theoretically, but this kind of questions are the ones that help me most)

Due to their usage in various specs and discussions (rather than their
definitions in 1.1), the terms 'variant' and 'content negotiation'
imply, for most readers, that a choice is being made between a few
different representations which are present _at one point in time_.

If a CGI script constructs a completely different entity from scratch
for every remote IP address, it is better to call this 'dynamic
content' or a 'dynamic resource', and not talk about content
negotiation.  One would say that the script computes 'representations'
or 'entities', not 'variants'.

While one could theoretically say that dynamic content is a special
case of, or the same as, content negotiation, doing so in practice
would dilute the term content negotiation, and would be more confusing
than helpful.

>
>Thanks a lot
>
>Jacob

Koen.

Received on Friday, 9 April 1999 20:19:35 UTC