RE: Hierarchical URLs and Collections

I have a resource called http://a/b/c. I delete http://a/b. Is http://a/b/c
deleted?

		Yaron

> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Thursday, August 20, 1998 7:38 PM
> To: Jim Davis; Falkenhainer, Brian C
> Cc: WebDAV working group
> Subject: 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 Friday, 21 August 1998 00:06:05 UTC