Re: Qualities of URLs and resources

>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