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

Re: Re (4): collection version resources

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 15 Jan 2001 20:01:11 -0500 (EST)
Message-Id: <200101160101.UAA16316@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
   From: Edgar@EdgarSchwarz.de

   ... could you give an example
   for the use of subbaselines ? I'm not sure whether it must be in
   the draft, but I think I need some more information on them.

Suppose you have three collections that are under baseline
control: /subsys/x, /subsys/y, and /system/a.  Now suppose that
a particular configuration of /system/a uses particular configurations
of /subsys/x and /subsys/y.  In order to capture that, you can
create a new baseline of /system/a which has as sub-baselines the
appropriate baselines of /subsys/x and /subsys/y.

   A question to the server writers out there: Is it clear to you how
   to implement subbaselines ?

There are a variety of ways to implement it.  One simple way would
be to implement the protocol directly, and just store away the URL's
for the subbaselines in the appropriate property.  But you could
also use repository labels or other techniques. 

   Perhaps you could also expain what it would mean when shared units
   are "below" the system that uses them.

This is "below" in a collection membership sense, i.e. a collection
that is a member of another collection is "below" that other

   And what's the difference
   between a "below" collection and a "below" subbaseline ?

In the earlier example, the baseline of /system/a has subbaselines in
/subsys/x and /subsys/y, but neither of these collections are "below"
(i.e. members of) /system/a.

   > I have written a Rose model that does this.  If I can carve out some
   > time, I'll publish this to the deltav web site.

   I still would like to see this Rose model. Could you put it somewhere
   on the Delta-V page in a format also readable by non Rose users ?

Definitely!  Unfortunately, I haven't been able to carve out the time yet,
but still hoping to do so in the not-to-distant future.

   A while ago there was the discussion on mutability. Finally you
   decided to kill it by variants.

Well, I'd have said "solved the problem in an interoperable way with
variants" (:-).  What got killed was the interoperability problem.

   Are the mutable champions happy now ?

Verbally, both Lisa and Mark have indicated that they are.  If not,
now's the time to post!

   I still think my proposal with a simple lifecycle where the initial
   state is still mutable would be easy to understand. Also it would
   give some guidelines how to implement more complex lifecycles which
   you find in many CM tools.

The lifecyle approach was not able to deal with the "human meaningful
URL" aspect of the mutable version problem.

   Also the discussion on human readable version URLs suddenly seems
   to be finished.

Yes, because the variant option provides human-meaningful names.

   When I had a look at the options we have, I noticed that they are orthogonal
   at first glance. But nevertheless there are certain sets of options which
   should be implemented together to get a certain functionality.

That is certainly true.  By orthogonal, we mean that all options make
sense independent of the others, but are compatible with each other
(i.e. implementing one option does not decrease/harm the functionality
provided by another option).

But this does raise a good point wrt the "workspace option".  Workspaces
are designed so that "baselining" and "merging" would be unambiguous.
Which means that there is not much point implementing workspaces if
you are not implementing baselining or merging.

I'm tempted to suggest that we define the workspace option as implying
support for both the "baseline option" and the "merge option".  Does
anyone object?

Received on Monday, 15 January 2001 20:02:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC