Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
jamsden@us.ibm.com
Thu, 21 Jan 1999 11:07:01 -0500
From: jamsden@us.ibm.com
To: Yaron Goland <yarong@microsoft.com>
cc: gclemm@tantalum.atria.com, ietf-dav-versioning@w3.org
Message-ID: <85256700.0058E29D.00@d54mta03.raleigh.ibm.com>
Date: Thu, 21 Jan 1999 11:07:01 -0500
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
1) Should mutable resource management be in-scope for
WebDAV?
2) Are the mutable resource and versioning models similar
enough to justify worrying about their interoperability?
Yaron,
There seems to be versioning WG consensus that 1) should be in scope in
order to provide sufficient for typical document management system
semantics. A number members, including myself and Geoff Clemm feel that
mutable revisions compromise versioning and configuration management and
should not be included in the protocol. However, we found that in order to
make progress, we had to yield and support the more flexible DMS semantics.
On your second question, this was discussed at length in the Portland WG
meeting, and it was generally agreed that the DMS servers didn't want to
have a separate protocol, but wanted to share most of the semantics of more
formal versioning systems, but with the additional freedom to change
revisions. Interoperability was a secondary goal, and as you point out,
clients from both camps could be confused by servers supporting the other
camp. This is an unfortunate result of having a lot of options.
This issue has consumed a lot of the versioning WG's attention and effort,
perhaps at the cost of reaching consensus in other important areas. I think
we should formulate use cases that motivate these various semantic
alternatives, and look for common agreement. I also think we need to focus
on semantic coverage of versioning, parallel development, and configuration
management before we introduce semantic variants, options, and
optimizations. Otherwise we run the risk of including some feature only to
discover it doesn't make sense in the context of other features.
For example, in systems that support parallel development, when activities
are merged, the system can generate the conflicts list, and can maintain
the list as they are resolved by the author. Having this capability is of
enormous importance because it helps make sure changes aren't lost. If
revisions are allowed to change, then an author cannot rely on the
conflicts list. New conflicts could be created at any time without any
record. Similarly, changing revisions of resources in a configuration used
to deploy a web application compromises the ability to re-create a
particular distribution. Sure, changing a spelling mistake in a document
might not have any significant effect on the configuration, but what about
changing an assignment in a script that is part of an HTML page? Where does
it stop? Is this something you want to leave up to any author to decide?
Authoring web resources is much more than authoring static documents, and
the versioning requirements are much stricter. The question is, do document
management systems have the same semantics? Should they? Do they care about
parallel development and configurations? How many options do we expect
client applications to deal with? Are these issues we want to resolve in
the protocol, or are they client issues?