W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: Hierarchical URLs and Collections

From: Yaron Goland <yarong@microsoft.com>
Date: Thu, 20 Aug 1998 21:06:26 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792423@RED-MSG-59>
To: "'Larry Masinter'" <masinter@parc.xerox.com>, Jim Davis <jdavis@parc.xerox.com>, "Falkenhainer, Brian C" <BFalkenhainer@crt.xerox.com>
Cc: WebDAV working group <w3c-dist-auth@w3.org>
I have a resource called http://a/b/c. I delete http://a/b. Is http://a/b/c


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC