Re: Draft IETF DeltaV Versioning

   From: "James J. Hunt" <jjh@ira.uka.de>

   Valid XML should be used in WebDAV instead of simply well formed XML

I believe that the benefits of XML validation is minimal at best.  It
really doesn't matter all that much if the errors are found by the XML
parser or by the semantic routine that actually does the work
following parsing.  DTD's are just not a good way of defining the
syntax of XML elements that are intended to be extended by later
versions of the protocol.

   Another problem is to track version information about the protocols.
   The DAV header as returned from an OPTIONS request (e.g.: "DAV: 1, 2,
   version-selector-checkout") does not help at all.  However, when using
   a DTD, the client and the server could agree on a protocol revision
   (or otherwise stop communication with an appropriate error message or
   log) by using the DTD's header information.

Since any new XML element MUST (according to 2518) be ignorable,
a client should not stop communication when it encounters a different
protocol revision, but rather should just ignore elements that it
does not understand ... that's what gets you interoperability.

   Labels in DeltaV
   ================

   One of the recent changes in DeltaV was to remove labels from the core
   versioning part and put them into the options part of the protocol.
   We strongly suggest to undo this change.  Even if there exist two or
   three revision control systems that do not use labels, labels are
   essential for identifying sets of associated files in a repository of
   versions.  And, actually, they are really easy to implement
   (especially on top of a WebDAV implementation that requires built-in
   mechanisms for property storage).

I agree with Lisa that identifying sets of associated files in a
repository is not a required feature of versioning in a document
management system.

In addition, labels are not a "good" way of indentifying associated
files in a repository because they require write access to the
version, when you should only need read access to generate a
reference.  Furthermore, they are even worse in a distributed
repository, since they require you have access to all the versions of a
version history, which makes a distributed implementation of the
version history infeasible (one of the versioning goals was to
define a protocol that was not incompatible with a distributed
implementation).

A significantly better way to identify sets of associated files is with
baselines.  A baseline has references to versions, and therefore
only read access to the version is required to create a baseline,
and unlike a label, a baseline does not require scanning all other
versions of that version history and therefore supports a distributed
implementation.

Since labels are a common implementation in non-distributed software
versioning systems, it is reasonable to define a standard way to
manipulate them, but since they are not required by document
management versioning, and are incompatible with distributed
versioning systems, I do not believe it is appropriate to make
support for them be mandantory.

Cheers,
Geoff

Received on Friday, 1 December 2000 17:56:53 UTC