- From: Yaron Goland <yarong@microsoft.com>
- Date: Thu, 12 Nov 1998 17:07:41 -0800
- To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: w3c-dist-auth@w3.org
BTW, my comment and Jim's comment are actually identical. Mine was just shorter. =) The thing to keep in mind is that because R1 claims DAV compliance and R4 claims DAV compliant, R4 MUST be a child of R1 as I specified previously. Yaron -----Original Message----- From: Jim Whitehead [mailto:ejw@ics.uci.edu] Sent: Thursday, November 12, 1998 4:41 PM To: Roy T. Fielding Cc: w3c-dist-auth@w3.org Subject: 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 20:07:43 UTC