- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Thu, 4 Jul 2002 15:40:55 -0400
- 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 available. > 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. Jonathan
Received on Thursday, 4 July 2002 15:55:22 UTC