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
Forwarded message 1
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