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

Re: Comments on WEBDAV-06 Draft

From: Surendra Reddy <SKREDDY@us.oracle.com>
Date: 22 Jan 98 09:11:41 -0800
Message-Id: <199801221724.JAA16835@mailtst1>
To: ejw@ics.uci.edu
Cc: <w3c-dist-auth@w3.org>
Here are my comments on GETCOL method. My comments are marked with [SKREDDY]

[Jim ]
... The mechanism used to retrieve a listing of the members of a collection
is 
... the PROPFIND method.  This, combined with the MUST-level requirement
that 
... all DAV-compliant resources provide a resourcetype property (indicating 
... whether the resource is, or is not a collection) allows a DAV client to 
... discover the hierarchy of a WebDAV namespace. The example in Section
7.1.3 
... shows a PROPFIND being used in a manner to retrieve the members of a 
... collection, and their properties.  This information can be used by a
client 
... to create a directory listing.

... It is true that there is no method which returns only just the member 
... collections of a collection, you must retrieve the names of
non-collection 
... and collection members of a collection together.  However, since
PROPFIND 
... gives you the ability to specify a minimal request for only just the
names 
... and the resourcetype property, the extra overhead of receiving the 
... non-collection members along with the collection members can be reduced. 
... Furthermore, the work of the DASL (DAV Searching and Locating) group 
... should allow for searches which retrieve only the collection members.

[SKREDDY]

In my opinion, I still recommend having GETCOL method. PROPFIND providing
extended services gives wider range of options to  webdav clients to discover
more about collections or any resource. GETCOL provides more power
collection operation
to get a hierachical view of the collection(s).  If WEBDAV client wants to
get a resource
property and its members, PROPFIND gives an excellent options to restrict
the scope of
an operation. But if client(need not be a browse-, assume an information
navigator, which provides
a read only view of the document repository) doesnot want to discover about
its properties and just need to
explore what is there in the server name space, I would recommend GETCOL
provide this functionality
rather than PROPFIND. Also, adding GETCOL separates collection(s) explore
operation
from collection property explore mechanism.

   Appreciate your comments.

best regards,

Surendra

attached mail follows:


Surenda,

Thank you for your comments on the -06 version of the distributed authoring 
protocol draft. My comments are below:

On Tuesday, January 20, 1998 3:26 PM, Surendra Reddy 
[SMTP:SKREDDY@us.oracle.com] wrote:
>    Enclosed are some comments on WEBDAV draft:
>
>
> 	(1).  	Is there any way I can get complete list of collections(top level 
or
> exploded ) in the server name space and
> 		its properties? Since there is no change in GET semantics for 
Collections,
> GET may return
> 		index.html or contents of this collection. How do I get only members in
> the collection
> 		and its properties with filters ( filtering collections not needed so 
on
> etc.)?  This operation may not
> 		be required in producer point of view -- but as a consumer if I wanted 
to
> retrive all collections
> 		filtering out some collections using some criteria -- we definitely 
need
> an enhanced GET semantics
> 		or GETCOL operation.
>
> 		If GET operation on collections simply returns whatever it contains or
> index.html
> 		how does Access Control List applies to collections?

The mechanism used to retrieve a listing of the members of a collection is 
the PROPFIND method.  This, combined with the MUST-level requirement that 
all DAV-compliant resources provide a resourcetype property (indicating 
whether the resource is, or is not a collection) allows a DAV client to 
discover the hierarchy of a WebDAV namespace. The example in Section 7.1.3 
shows a PROPFIND being used in a manner to retrieve the members of a 
collection, and their properties.  This information can be used by a client 
to create a directory listing.

It is true that there is no method which returns only just the member 
collections of a collection, you must retrieve the names of non-collection 
and collection members of a collection together.  However, since PROPFIND 
gives you the ability to specify a minimal request for only just the names 
and the resourcetype property, the extra overhead of receiving the 
non-collection members along with the collection members can be reduced. 
 Furthermore, the work of the DASL (DAV Searching and Locating) group 
should allow for searches which retrieve only the collection members.

When you think about it, directory listing commands like DIR and ls return 
the names of the members of a collection, along with selected pieces of 
metadata about those members (size, access permissions, last modified date, 
etc.).  Since WebDAV allows a wide range of metadata to be defined on a 
resource, it is difficult to pick the "minimal" set of metadata which 
should be returned by a collection-listing command.  In the end, the 
solution chosen was to provide a general mechanism for retrieving 
properties, allowing clients to create their own list of properties to 
return when listing the members of a collection.

>
> 	(2).	Can we add GETCOL to supporting listing of all collections and
> properties of each collection
> 		with an optin for scope parameters -- get list of collections from the
> root or
> 		get list of all collections within the given collection and so on. This
> facilitates to
> 		clients to discover  the server name space hierarchies and explore 
them.

Given that PROPFIND allows a client to discover the hierarchy of a 
collection, do you still feel there is a need for a GETCOL method?

>
> 	(3).	Does WebDAV protocol support maintaining source ( non-html) and 
html
> resources? If I am using word processor to
> 		create documents and publish it ( both source and html), how does one 
get
> source documents?

WebDAV provides a source link (a property with specific syntax and 
semantics) which can be used to point from the derived resource to the 
source resource.  In your example, the DAV-client would set the source link 
on the html resource and have it point to the source resource.  HTTP (and 
hence WebDAV) places no restrictions on the content which can be 
transferred using the protocol, and hence a word processor resource can 
easily be authored using WebDAV.


> 	(4).	Versioning
> 	
> 		What is the time frame for Versioning specification?

Ah yes, what about the forgotten V?  The plan is to start working on 
versioning in the very near future, with an aim towards submitting a 
versioning specification to the IESG in '98.

> 		
> 	(5).	When it supports a resource checkout and checkin operations, do we
> still need LOCK and UNLOCK
> 		operations? Doesn't it handled in Checkout and Checkin operations?
>

A fine question, one which I'll defer to later discussion on versioning. 
 However, you may want to check out this excellent message from Chris 
Seiwald, located in our archives:

http://lists.w3.org/Archives/Public/w3c-dist-auth/1996JulSep/0032.html

In it, Chris talks about the various meanings of lock/checkout and 
unlock/checkin like operations for various versioning/CM systems.

- Jim

 
Received on Thursday, 22 January 1998 12:24:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:44 GMT