Comments on WebDav draft

Enclosed are some comments on the WEBDAV draft.  I've
just started following the mailing list, so let me apologize
up front for not having pawed through the archives and
meeting minutes to see how these issues have been dealt with
in the past.  If any of the issues I address have been
definitively resolved, I'd appreciate a pointer to the
relevant message or meeting minutes.

  -- Ellis Cohen
     Crystaliz

===================================================

1) Initial properties

One of the ways we expect to use properties is to indicate
the type or storage model of the associated resource.  If
PUT is used to create a new resource, we need a way of
specifying its initial properties.

I'm guessing that PROPPATCH can be used to define the
properties of a resource even before doing an initial PUT to
create the contents of the resource.  I can't see anything
in the spec that suggests that this would be illegal.
Assuming we're in agreement that it makes sense, there
probably should be some wording that acknowledges this use.

2) PUTs and PropLocs

I can't immediately see a strong reason to provide PropLocs
in the first place, but given that they're, why only allow
GETs on them and not PUTs?  I don't find the argument in
2.8.4 very compelling.

3) Deleting Collections with Children

3.1.2.1 and 3.5.4 point out that if a DELETE on a collection
with internal members must fail.  This might be reasonable
if there were a DELCOL operation.  Since there's not one, it
means that each member must first be deleted.  This doesn't
seem either reasonable or consistent with existing
collection-like API's.

4) Named Collection Members

Since file system directories are meant to be modelled by
collections, I'm a bit surprised that there is no support
for something equivalent to named links.  I'd like to see
something like an optional Collection-Member-Name header
added to ADDREF.  This would also support ordering (i.e. use
numbers for names) for those who care.  The constraint
against duplicate external URI's would, of course, now only
apply to unnamed members.

I realize that named external members can be modelled by an
internal member whose content is the URI, but this leaves
the semantics (of following the link) up to the end-user or
application, which seems completely inappropriate.

If .../a/b/ is a collection, and c is the name of an
external reference to .../foo, there is a question of what a
GET on .../a/b/c should return.  Either it could return a
Redirection response (e.g. 303) to .../foo, or it go get
.../foo itself.  I'd go for leaving it up to the server,
although perhaps an optional Binding header could be used to
provide a hint.

Naturally DELREF could use either Collection-Member-Name or
Collection-Member.  Also the ResInfo element should now
include the name (in fact, for internal resources, perhaps
this should be provided instead of the Href).

5) Types for Properties

It would be useful to be able to associate some sort of type
with a property.  I'm not saying that WebDav need provide
any interpretation of the property type, but I do think it
would be useful for a property schema to have an optional
type associated with each property.

6) Relationship to RDF

There seem to be many similarities between RDF and WebDav.
Is someone responsible for making sure that they don't have
unnecessary incompatibilities or different approaches to the
same issue?

7) Binding of External References

External references (especially if they're named) correspond
to what directory systems refer to as "soft links".  If
collections are going to reasonably reflect existing
directory systems, it is worth considering "hard links" as
well, where the underlying system can accomodate it.  An
optional Binding header can also be used to support this.
Support for hard links impacts the ResInfo element -- it
probably should only provide the name, and some token
indicating a hard link, rather than an Href.

By the way, "partial links" (where the initial part of the
URI is treated as hard, and the trailing part of the name is
soft) are also useful, particularly in version management
systems (where the description of which version to get is
soft, while the name of the versioned object itself is
hard-linked).

Finally, there is the matter of "indirect links", akin to
COM's monikers.  The resource to which an external member
refers (by a hard, soft, or partial link) may contain a
value which is (or can be interpreted to resolve to) yet
another URI (which could again be either redirected or
retrieved directly).

At this late date, I'd like to just raise this issue, but
not argue strongly for it.  Unless there's other support,
this could easily be left for a subsequent revision.

8) Member properties

Some directory systems support properties on the links to
external resources, independent from the properties on the
resources themselves.  For instance, access privileges are
often associated with the link, meaning that the access
rights one has to a resource may depend on the path used to
name it.  Again, I'd just like to raise this issue, but not
necessarily argue for it.

--- fin

Received on Thursday, 30 October 1997 17:03:56 UTC