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

RE: Baselines and Bindings

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Thu, 11 Oct 2001 14:11:22 +0100
Message-ID: <20CF1CE11441D411919C0008C7C5A13B02AD3C11@stalmail.eu.merant.com>
To: "Clemm, Geoff" <gclemm@rational.com>, ietf-dav-versioning@w3.org
Hi,

[Geoff wrote]:

>Although the protocol does not require the baseline to
>remember the names of members from other baselines, it certainly
>can do so...

Thanks Geoff, that makes sense.

1. Why not make this the recommended behaviour (that servers SHOULD capture
the names of resources
that appear in other configurations, rather than not include those resources
in the baseline).

2. Another possibility would be to make this client-driven, eg let the
client send a XML element 
in the body of the BASELINE-CONTROL or CHECKIN of a VCCn request to indicate
that it wants 
names captured for resources that appear in other configurations).


It seems like such crucial data (in order to make the baseline a consistent
snapshot of the
baseline-controlled collection).

Any preferences as to which of the above approaches?

I could add it to my proposed baseline feature extensions/clarifications?

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com



-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 11 October 2001 13:43
To: ietf-dav-versioning@w3.org
Subject: RE: Baselines and Bindings


   From: Peter Raymond [mailto:Peter.Raymond@merant.com]

   I understand why the baseline of cmp2 would not contain a 
   version of /ws/cmp2/src/bar.html, but this does seem odd. 

   I can think of a common use case for which this may cause problems: 
   ...
   /ws/project1/news/adverts.js is just a binding to 
   the VCR at /ws/project1/adverts.js.

   BASELINE-CONTROL on /ws/project1/news
   BASELINE-CONTROL on /ws/project1

   according to Geoffs e-mail I think this will NOT contain
   adverts.js, it will only capture the default.htm, because the VCR
   for adverts.js already has a DAV:version-controlled-configuration
   property and so cannot be a member of two configurations.

Correct.

   This seems really odd, because now if you use BASELINE-CONTROL to
   populate a new collection with the contents of the baseline that
   you took of /ws/project1 it will NOT create a advert.js at the top
   level and so the web page would be broken!

Yes, because baselines of project1 depend on baselines of news,
so you only get consistent states if you have baselines of project1
contain a subbaseline of news.

   Even if the baseline of
   /ws/project1/news was a subbaseline of the baseline of
   /ws/project1, the adverts.js would still NOT be created at the top
   level when the /ws/project1 baseline is used.

Why not?  Although the protocol does not require the baseline to
remember the names of members from other baselines, it certainly
can do so, in which case it will know to populate /ws/project1/advert.js
with a binding to the same VCR as /ws/project1/news/advert.js.
If the server supports VCCls, then if for sure will track this information
in the binding-set of the collection version for /ws/project1.

   I don't have a good
   answer to how I would propose we fix this, but it certainly seems
   like a problem.  We could always just capture one baseline of
   /ws/project1 and NOT capture /ws/project1/news as a baseline (eg
   just have one baseline of the whole thing), but this is forcing the
   user down this route, they may have wanted to track
   /ws/project1/news as a component.  Am I on track? 

I think the only thing you missed is that a baseline is allowed
(and if it supports VCls, required) to track the names of members
from other configurations.

Cheers,
Geoff
Received on Thursday, 11 October 2001 09:13:19 GMT

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