- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Fri, 25 Feb 2000 16:48:40 -0800
- To: "Clemm, Geoff" <gclemm@rational.com>
- cc: w3c-dist-auth@w3.org
>Every concept is referenceable, so your definition would >make the term "resource" a synonym for the term "concept". >This makes the term "resource" useless, since >the term "concept" is well defined, and adding a synonym >for it does not buy us anything. A resource is what you get when you give a concept an identifier and allow authors to reference it. Not all concepts are given resource identifiers. I'm not trying to sell you anything -- I am stating a fact. URIs identify resources. Resources are defined in RFC 2396. WebDAV is chartered to define an authoring interface to resources. It is not chartered to define a remote document management interface that only uses HTTP to get through firewalls. That means WebDAV needs to deal with an interface where only a subset of the identified resources are directly authorable. There are lots of ways to deal with that issue. Just about the only one that is completely unacceptable is what the bindings and references specs currently do: redefine the term "resource" to mean something else that is easier to interpret as an authoring widget. >An alternative definition is that a resource is a function >that can be associated with a URI, where the input to this >function is a method name, a request URI, a list of headers, >and a request body, and the output is a list of headers and >a response body. (I pretty much copied this definition from >one of your earlier posts, so I make no claim of originality >here). The resource is a semantic mapping. The function is how that mapping is implemented on the server at the time of the request. The function changes, the values in response to the function change, but the resource hopefully does not. (Of course, the resource does change at times, resulting in one of the forms of "broken" links described in my 1994 paper on MOMspider, but the goal here is to provide identifiers that change as little as humanly possible). >In this alternative definition, all sorts of concepts are not >resources ... in particular, a method name is not a resource, >a header is not a resource, a request or response body is not >a resource, and a URI is not a resource. On the contrary, all of those can be resources -- they are just referenced by some other URI and accessed in some other request and representable in some other responses. That is why I said that you can't explicitly say that they are not resources, even though they are not *the* resource that is the target of *that* request. >I believe this alternative definition is far more useful for >defining a binding protocol. I'm willing to use some other >term for this alternative concept, if it is important to reserve >"resource" as a synonym for "concept", but my impression is >that this alternative definition is the more commonly accepted >one. None of this is necessary for defining the protocol. The reason why the specs have so many errors in this regard is because they overspecify the protocol to the point where it limits implementations to something far less than Web resources. Just delete those parts and define it in terms of the collection namespace. ....Roy
Received on Friday, 25 February 2000 19:48:45 UTC