RE: Spec clarifications

Sanford, your points are dead on and identify the areas where WebDAV is
working. However I think the core of your concern is the perception that
somehow the current Distributed Authoring spec is the end of the process.
The DA spec is only the first step in a series of specification. It provides
the most absolute basic functions which will then be leveraged by the other
specs. So, for example, the next two specs that this working group has
committed to delivering are Access Control Lists and Versioning. In addition
a new working group on Search is being formed which is also leveraging the
DAV specs as its foundation.

Staged Systems - Staged systems are very common, even before the web.
However you will notice that the DA spec works perfectly well as a
communication mechanism between the editing software and the first stage.
What is missing is the ability to say "roll this out." The reason that
functionality is not in the spec is that so many systems implement this
function in so many incompatible ways that the working group came to the
decision that it wasn't practical to standardize this functionality. You can
only standardize something that is very well understood and is done in
essentially the same way by everyone. Standards are not the way to get
everyone to agree to do the same thing. Standards are what you use to
formalize matters once everyone is doing the same thing, the same way.
However the beauty of the DAV specs is that they are like Lego blocks. So
you can easily take the DA spec and the V spec and the ACL spec and put them
together with a submit command spec. Old DA only compliant systems will
still work and will only need a little extra software to be able to give the
submit command.

Locking - See section 4.2. But in what I suspect may be a more useful answer
to your question, systems which choose not to supporting write locks will
suffer from the lost update problem. That is their choice. Although many
systems which do not use locks or use shared write locks instead depend upon
advanced merging facilities. The Versioning spec will be addressing the
issue of how to handle merging.

Lock Ordering - There is no lock ordering requirement, that is completely
under the control of the client. If you want to make sure you don't have
lost update issues make sure you lock before you do the GET. 

Discovering the Source - I'm not sure what more I can say that isn't already
said in section 12.11.

What can be stored in properties - Section 2.4: "The value of a property is
expressed as a well-formed XML document." I'm not sure what more can be
said.  As for size limits, that is implementation specific.

Reservations - Versioning, including reservations and such, will be dealt
with in its own specification.

		Yaron


> -----Original Message-----
> From:	Sanford L. Barr [SMTP:sbarr@interwoven.com]
> Sent:	Wednesday, February 11, 1998 7:22 PM
> To:	'w3c-dist-auth@w3.org'
> Cc:	'sbarr@interwoven.com'
> Subject:	Spec clarifications
> 
> 
> 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 Thursday, 12 February 1998 01:40:34 UTC