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

Spec clarifications

From: Sanford L. Barr <sbarr@interwoven.com>
Date: Wed, 11 Feb 1998 19:21:50 -0800
Message-ID: <01BD3722.4E534E20.sbarr@interwoven.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Cc: "'sbarr@interwoven.com'" <sbarr@interwoven.com>

After reviewing the current -06 draft and mentally mapping the protocol 
onto existing web collaboration systems, I have the following questions. 
 Since I'm new to the spec, I apologize if I'm rehashing items that have 
already been discussed and clarified:

As I read the spec it seems that the current WEBDAV protocol is very single 
site, live content centric (content is taken directly from a live site, 
edited and returned directly to the live site).  In all but the simplest 
organizations this usually isn't the case.  Most corporations that I'm 
familliar with have development servers (staging servers, with individuals 
having separate workareas) from which content is then moved to QA [legal, 
etc.] and then eventually through to a production server.  It doesnt seem 
clear from the current spec how these common authoring environments are 
addressed by the current WEBDAV draft.  The best I can guess is that a 
'PUT' and the associated 'UNLOCK' could be overloaded to imply an 'OK move 
the content to the next stage' but a more explicit 'SUBMIT' (an explicit 
command signifying the completion of a specified unit of work which would 
trigger additional workflow) on a collection of associated items seems more 
in order.

Has the working group already discussed an approach to this scenario using 
the current set of defined methods?

There are also some specifics that seem unclear at first reading:

*) Client requirements for locking support

There doesn't seem to be any client requirements for forcing locks to be 
used if they're supported by the WEBDAV server.  If locking support (if it 
exists on the WEBDAV server) is not strictly required of the clients, the 
"Lost Update" problem will still persist (A does a GET, B does a LOCK, GET, 
edit then PUT, UNLOCK, A then does a PUT overwriting B's changes).

*) Client lock ordering.  The spec doesn't seem to make mention of the 
order of operations when locks are involved.  Specifically, If a client 
chooses to edit, and locking is supported, the file must be locked before 
the edit can begin, otherwise conflicts can occur.  Currently it seems ok 
for a client to do a 'GET' and then later try to acquire the lock on the 
item in question (opening up the possibility for the "Lost Update" scenario 
above).  Actually as I reread page 14 it does loosely imply the 
lock/get/put/unlock ordering, but this could be more explicit.

*) How to discover "real" source of a file (seems vague from spec)

As noted in the spec, one of the more common operations is how to discover 
the real source(s) of a rendered file (i.e. a file with server side 
includes).  The current draft refers to inline 'links', but seems vague. 
 Was there any consideration of using live properties or another more 
defined method to address this?

*) What can be stored in properties (arbitrary unicode for dead and live 
values?), any size limits, etc?

*) No provision for submission 'Reservations'

The spec only addresses explicit write lock, discusses shared lock but 
punts on recommondations.  Many site management systems have a concept of a 
'Reservation' (guarantee to submit without conflict, while others may still 
be allowed to merge).  While it seems that the current spec has sidestepped 
version control - not being able to coexist with existing systems and 
detect conflicts seems to be a significant drawback.  Overall the exclusion 
of versioning in this draft renders the spec almost unusable except for 
extremely small scale sites (a handful of non conflicting contributors).

In closing, I'm hoping that the working group will take a careful 
consideration of the issues involved with WEBDAV integrating with existing 
versioning and workflow systems before ratifying the current draft 
specification.  I'd personally like to see the industry adopt WEBDAV, but 
in it's current form, the omission of versioning and the lack of enabling 
even the most simple workflow trigger (collection submit) seems to limit 
its overall usefulness, and makes it difficult to integrate effectively 
into existing site management, versioning and workflow systems.  I believe 
with a little extra refinement and discussion the current spec could be 
extended to address these needs.

Sanford L. Barr
Manager, Internet Technology Group
Interwoven, Inc. 885 N. San Antonio Rd., Los Altos, CA 94022 650/917-3600 
ext 219
Received on Wednesday, 11 February 1998 22:18:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC