From: firstname.lastname@example.org To: Yaron Goland <email@example.com> cc: firstname.lastname@example.org, email@example.com Message-ID: <85256700.0058E29D.firstname.lastname@example.org> 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?