Re: Activity, Workspace, Configuration

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Fri, 10 Dec 1999 00:25:34 -0500 

Date: Fri, 10 Dec 1999 00:25:34 -0500
Message-Id: <9912100525.AA02998@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256841.00680411.00@d54mta03.raleigh.ibm.com>
Subject: Re: Activity, Workspace, Configuration


   From: jamsden@us.ibm.com

   Budi Surjanto <surjanto@informatik.uni-kl.de> on 12/08/99 10:45:35 AM

   As explained, a collection and a configuration contains
   a set of versioned resources resp. revisions of versioned resources.
   What is exactly the semantic of the containment relationship?
   Is it the aggregation?

   <jra>
   Collections contain member URL segments, not resources or versioned
   resources. These segments represent bindings to some resource.
   Configurations contain members that are bindings to a particular revision
   of a versioned resource. So the containment relationship is to the
   bindings, not the resources themselves which could be stored somewhere
   else, or in some other collection.
   </jra>

This is made explicit in BIND protocol being developed by the advanced
collection team.  As Jim says, the state of a collection is a set of
bindings, where a binding is the association of a URL segment with a
resource.  The resource is owned by the server, and its lifetime is
not determined by the collection(s) that contain it (although a server
is allowed to garbage collect a resource that has no bindings to it).

   Is it correct that one can build collection resp. configuration
   hierarchically?

Yes for collections, and as Jim points out, no for configurations.
Baselines can be built hierarchically though.

   For example:
   A, B, C are versioned resources and {a1}, {b1}, and {c1} the corresponding
   revisions of each of them.
   CL1 and CL2 are collections whereas CL1 contains {A, CL2} and
   CL2 contains {B, C}.
   CO1 and CO2 are configurations whereas CO1 contains {a1, CO2}
   and CO2 contains {b1, c1}.

   In the latter case, if a revision c2 of c1 was made, does it effect
   some kind of "revision propagation" of the other revisions contained
   in the configuration hierarchy (CO1 and CO2), since they are
   related to each other in a some way?

   <jra>
   Configurations can't contain configurations. This is to keep revision
   selection simpler.
   </jra>

Even if configurations were allowed to be hierarchical, no such
revision propagation would be supported.  This kind of propagation
of change is provided through the revision-selection-rule mechanism
of the workspace.  In particular, the revision-selection-rule gives
the client the appropriate semantics for defining what kind of
propagation it wants to take place.

Cheers,
Geoff