RE: Clarification of URI vs. resource

Roy Fielding writes:
> My comment was regarding the requirement that DAV capable resources be
> within a DAV collection.  There is no need for that requirement and it
> is the root of many terminology issues.  Any individual resource is
> capable of being or not being DAVable, as determined by either the
> capabilities described by an OPTIONS response or by the error response
> received when attempting to do a WebDAV operation on a non-DAV resource.
> "Save as..." dialogs are cool, but not necessary, for authoring.

The primary rational for this requirement is to avoid some of the weird edge
cases which can occur when some URLs in an HTTP URL namespace are members of
a collection, and some are not.

For example, assume there are four resources, R1, R2, R3, and R4.  They are
accessible via 4 URLs, as follows:

http://www.example.org/collection/ --> R1
http://www.example.org/collection/index.html --> R2
http://www.example.org/collection/logo.gif --> R3
http://www.example.org/collection/other.html --> R4

Let us assume this is a non-consistent namespace, where collection resource
R1 contains only the following two relative URLs:

./index.html
./logo.gif

Importantly, collection resource R1 *does not* contain:

./other.html

This is what makes the namespace inconsistent.

Following the definition of DELETE, if a DELETE of Depth: infinity is
performed on http://www.example.org/collection/, resources R1, R2, and R3
will be deleted, but R4 will not.  That is, after a successful delete on
http://www.example.org/collection/, a GET on
http://www.example.org/collection/other.html will still return an entity
representation of R4. This was viewed as undesirable behavior, and led
directly to the requirement for consistent namespaces for DAV-compliant
resources.

In particular, this case creates odd cases for server implementors who use a
hierarchically structured repository, like a file system.  In the example
above, if the resources correspond to the following files:

R1 -> /home/ejw/public_html/collection/
R2 -> /home/ejw/public_html/collection/index.html
R3 -> /home/ejw/public_html/collection/logo.gif
R4 -> /home/ejw/public_html/collection/other.html

After the DELETE, the server will need to keep file
/home/ejw/public_html/collection/ around, but non-accessible (i.e., removing
the mapping of http://www.example.org/collection/ to this resource, but not
destroying the underlying chunk of state the resource was mapped to), in
order to ensure there is a container for
/home/ejw/public_html/collection/other.html  Alternately, the server could
decide to delete /home/ejw/public_html/collection/other.html so it can also
delete /home/ejw/public_html/collection/ (i.e., if the server treats the
request to delete the collection as being more important than preserving
resources which aren't a member of the collection).

So, to avoid these strange edge cases, and to avoid possible
interoperability problems they might cause, the Design Team felt it was
simpler to require consistency of the HTTP URL namespace for
WeBDAV-compliant resources than to place the burden on servers to implement
these edge cases correctly.

But, what I am hearing from some members of the working group is that they
would prefer to drop this requirement.

> Eliminating the unnecessary requirement also removes any need to talk
> about how many different URI reference the same resource

In the end, this had already boiled down to an editorial note that a
resource can have more than one URI. The major change was dealing with the
URI vs. resource distinction.


> Instead, just define what a collection contains (its own namespace)
> and how to get a representation of that collection.

What is your suggestion for how to do this in a precise way?  This is what
we were aiming for in our definition of namespace consistency.

- Jim

Received on Thursday, 12 November 1998 19:45:41 UTC