Subject: RE: Qualities of URLs and resources

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 25 Feb 2000 09:16:51 -0500

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.

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).

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.

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.

Cheers,
Geoff

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Friday, February 25, 2000 12:17 AM
> To: Clemm, Geoff
> Cc: Slein, Judith A; [email-masked]
> Subject: Re: Qualities of URLs and resources 
> 
> 
> >There are some concepts that explicitly are not resources,
> >e.g. the concept of a "URI" or the concept of a "property".
> 
> Nope.  If the concept is referenceable, it is a resource.  If you ask
> me for the URL that I was using to represent my home page in 1994,
> you are referring to a URI as a resource in itself.  All properties
> are resources -- DAV just defines a different way of accessing them
> than the old HTTP interface.  The only reason it did so is because
> some people felt that adding direct access to properties was better
> than paying for one round trip.
> 
> >Like URI's and properties, a binding is not
> >something that is identified by a URI, and is not something
> >to which you can apply requests.  Instead, a binding
> >is just a term we use to talk about how a collection 
> >resource behaves, e.g. if at time T, a collection resource has a
> >binding named "foo" to a resource with DAV:resourceid "xxx", then
> >this is just a shorthand for saying that a
> >depth:1 PROPFIND at time T on any URL that is mapped to that 
> collection
> >will return a DAV:response with a DAV:href whose value is 
> >"<that URL>/foo" and with a DAV:resourceid whose value is "xxx".
> >
> >In other words, all URI's that are mapped to that collection at time
> >T will have a member named foo, and the DAV:resourceid of that member
> >will be "xxx".
> 
> For any concept X, it is possible to create an identifier namespace
> obeying the requirements of RFC 2396 such that concept X is 
> unambiguously
> identified within the scope of the namespace's usage.  It is therefore
> possible to identify any concept with a URI, which makes it a 
> resource.
> 
> BTW, DAV:resourceid is an abomination.  It breaks the implementation
> abstraction that is at the core of the Web interface.  Telling server
> implementors to reveal that information is wrong and is completely
> unnecessary to define the protocol.
> 
> ....Roy
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 25 Feb 2000 16:48:40 -0800

>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.

>one of your earlier posts, so I make no claim of originality

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).

>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.
 
>that this alternative definition is the more commonly accepted

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