W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

RE: Re (3): Re[2]: baselines & namespaces

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 27 Dec 2001 16:07:18 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1053F6CEB@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Edgar@edgarschwarz.de [mailto:Edgar@edgarschwarz.de]

   >	Edgar@edgarschwarz.de schrieb:
   >    If /x/y is the root collection of another configuration it
   >    doesn't belong to /x and if it also isn't a subbaseline of /x
   >    it must not be created when /x is extracted in a new
   >    workspace.

   "Clemm, Geoff" <gclemm@rational.com> wrote:
   > If your server supports baselines but not versioned collections,
   > then it is not required to create /ws/kk/x/y when /repo/bl/22 is
   > merged into /ws/kk, but it may do so.

   Why should this be allowed ? A baseline "... captures the state of
   each version controlled member of a configuration.". So /ws/kk/x/y
   isn't captured in the baseline and I see no reason to restore it.

This is allowed to provide consistent semantics in the presence of
versioned collections.  A version of a collection captures a set of
version-controlled bindings, and an appropriately named binding to a
VCR must exist when that collection version is restored
(i.e. specified in the DAV:checked-in property of a version-controlled
collection).

   > If your server supports baselines and versioned collectios, then
   > it MUST create /ws/kk/x/y when /repo/bl/22 is merged into /ws/kk.

   Why should this be required ? /ws/kk/x/y wasn't captured in the
   baseline, so there is no information how to restore it.

The baseline /repo/bl/22 contains a collection version for "./x/y",
and this collection version has a version-controlled binding named
"y".  This means that after /repo/bl/22 is merged into /ws/kk, there
must be a VCR named "y" in the version-controlled collection
identified by /ws/kk/x.

   In your agenda BASELINE-CONTROL is giving different results
   depending on another 'competing' feature being supported or
   not. This shouldn't be.

That's why the server is given the "choice" of what to do.  If it does
not support version-controlled collections, it doesn't make sense to
require it create a VCR named /ws/kk/x/y.  But if it does support
version-controlled collections, then it doesn't make sense *not* to
create a VCR named /ws/kk/x/y.  So we leave this particular choice up
to the server.

Cheers,
Geoff
Received on Thursday, 27 December 2001 16:07:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT