RE: 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.

More than happy to provide it. You can do your due diligence at
http://www.ics.uci.edu/~ejw/authoring/. It contains the mail archives,
reference documents, meeting minutes, and so forth.

Initial Properties - Yes, you can do a PROPPATCH before doing a PUT. In
fact, the next version of the specification will even include a resource
type for you to use. It is a generalization of the iscollection property. As
for putting a specific reference, my own feeling is that the note is
unnecessary. However I am not deeply wed to that position.

PUTs and Proplocs - Proploc has been removed from the spec.

Deleting Collections - Please refer to the mailing list archives and the
tree draft available at
http://www.ics.uci.edu/~ejw/authoring/depth/draft-ietf-webdav-depth-00.txt.

Named Collection Links - Please refer to the mailing list archives for the
extended, torturous, endless, painful, debate on this subject. However a
quick summary is that many, if not most, file system can not readily support
named links. However the general WebDAV design philosophy is that there are
only two features, required and non-existent. So as this feature would have
to be made optional because many systems just can not support it, it was
decided to drop it. In fact external members were only adopted once the type
of recursive operations you see in the tree draft were made to NOT apply to
them. That way an OS which does not support any form of linking can record
external members as nothing more than an unnamed property.

Types for properties - Again, please refer to the mailing list where this
topic has been addressed. The solution is that all DAV properties are XML
documents. The XML and RDF efforts are directly dealing with the issue of
typing. Further information on those efforts are available at
http://www.w3.org. 

RDF - As previously mentioned, this topic has been address on this list, at
length and resolved with the help of the numerous DAV working group members
who are also members of the RDF working group. It has been established that
DAV is 100% plug and play compatible with RDF.

External References - The same reason used to rejected named collection
links was also used to reject external references. Actually external
references also fell afoul of another DAV design rule "DAV is done when
there is nothing left to cut." However, as with named collection links, both
features can be added on at a later date such that systems that wish to
support them can interoperate with those that do not.

Member Properties - The group has dealt with this problem under the heading
of hierarchical properties. After much debate it was decided to not support
them because many systems would be unable to handle them. In fact until
fairly recently the specification even included an entire section explaining
the logic of the decision. It is expected that the first extension to DAV,
down the road, will be hierarchical properties. I know it is something my
own company is keenly interested in.

			Yaron

> -----Original Message-----
> From:	Ellis Cohen [SMTP:elllis@crystaliz.com]
> Sent:	Thursday, October 30, 1997 2:10 PM
> To:	w3c-dist-auth@w3.org
> Subject:	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 Saturday, 1 November 1997 07:37:39 UTC