RE: Hierarchical URLs and Collections

This is an odd discussion, since people seem to be putting up
strawman proposals and then knocking them down.

The objection to the current WebDAV spec is that it requires the
client to parse the URL in ways that are otherwise not required.

I think part of the issue is that the 'parent' is an attribute
of the resource locator, and not an attribute of the resource itself.

The 'value' is that it no longer requires that the URL hierarchy
match the (direct) containment hierarchy.

For example, if put up a DAV server as

     http://myserver.com/people/masinter/cgi-bin/DAVSERVER/root

I might want to treat 'root' as a container, but not have the client
assume that the parent of 'root' is
    http://myserver.com/people/masinter/cgi-bin/DAVSERVER
and that the parent of that resource is
    http://myserver.com/people/masinter/cgi-bin/

etc.

Clients shouldn't parse URLs except to deal with relative references.

This is not a "multi-membership" issue, nor a direct vs. referential issue;
those are perhaps issues too, but let's leave them aside for now. 

The issue is that currently the semantic concept of direct
containment is equated with syntactic MUST constraints on the URL syntax.

That syntactic mapping is certainly required by most file systems, but
it shouldn't be required here.

From "4.1 Collection Resources" of the April 7 (version 08) draft:
> 
>    A collection is a resource whose state consists of at least a list
>    of internal members and a set of properties, but which may have
>    additional state such as entity bodies returned by GET.  An internal
>    member resource MUST have a URI that is immediately relative to the
>    base URI of the collection.  That is, the internal member's URI is
>    equal to the parent collection's URI plus an additional segment
>    where segment is defined in section 3.2.1 of RFC 2068 [Fielding et
>    al., 1996].
> 

There are NO OTHER parts of the web or the WebDAV protocol that 
require this constraint. The DocuShare WebDAV-style Windows client works
without that constraint because it deals with the content of
PROPFIND requests, not the syntax of resource URLs. You certainly don't
need the syntax to walk down the tree - PROPFIND clearly tells what a
collection's members are.

If we add a server-side operation for obtaining the DAV 'parent' of a
resource (locator), then that kind of approach to walking the hierarchy
will be more general and more robust. The _server_ should be
the source of hierarchical knowledge, not the client or syntactic
conventions. The server would then be free to store and reference
content as it wishes and the client doesn't need to care.

It may have confused the issue to make this operation 'PROPFIND', since it
doesn't actually apply to the resource but to the locator.

Larry
--
http://www.parc.xerox.com/masinter

Received on Thursday, 20 August 1998 22:37:37 UTC