W3C home > Mailing lists > Public > www-tag@w3.org > July 2002

Re: Representations of Resources and Precision of Denotation (was Re: TB16 Re: Comments on arch doc draft)

From: Jonathan Borden <jonathan@openhealth.org>
Date: Thu, 4 Jul 2002 15:40:55 -0400
Message-ID: <019501c22392$b7199660$0201a8c0@ne.mediaone.net>
To: "Patrick Stickler" <patrick.stickler@nokia.com>, "ext Paul Prescod" <paul@prescod.net>
Cc: "WWW TAG" <www-tag@w3.org>

Patrick Stickler wrote:

> Sorry, but I interpret this as meaning a rock is a resource and a
> textual description of a rock is a resource, and those are two different
> resources. The former cannot be retrieved -- no representation is
> The latter potentially can be retrieved -- one or more representations may
> be available.
> I've never understood any of the HTTP or REST materials as saying that
> a textual description of a resource is a representation of that resource.

A textual description of a resource is a representation of that resource.
You read that here. Reread the message from principal author of RFC 2068 and
REST. You've read this and this is how the community defines the terms.


> You are using the word "representation" too broadly. It is not
> possible (with current technology) to create an HTTP representation
> of a rock.
> Yes, in English, we say that a photo provides a kind of representation
> of the rock, but that's not what HTTP means by "representation".

That _is exactly_ what HTTP means by "representation". Just as in English.

> Quite so, but this is a matter of resolution. I give unique URIs
> to both resources and their variants, but as each variant is
> a valid realization/representation of the resource, content negotiation
> is free to return a variant *as* the resource -- which it is.

No. HTTP _never_ returns a resource, _only ever_ a representation of that
resource. By definition. This point is non-negotiable.

Since this issue appears not to be uniformly understood, the architecture
document should  repeat it and make it crystal clear. It is an axiom.

Received on Thursday, 4 July 2002 15:55:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:52 UTC