Re: Configurations, sets and collections

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 9 May 1999 23:21:49 -0400 

Date: Sun, 9 May 1999 23:21:49 -0400
Message-Id: <9905100321.AA10403@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Configurations, sets and collections

I'd slightly rephrase Brad's definition (quoted below) to say:

"A configuration must immutably map a versioned-resource with
a specific versioned-resource-id to a revision (of that
versioned-resource) with a specific revision-id."

This definition allows the server to just store the id-mapping
itself, just store the name of some immutable label placed on
the appropriate revisions, or use any other means that produces
this immutable mapping.

I'd slightly rephrase Jim's definition to not use the
term "bind", since the advanced collections spec will
be defining that term to have very specific semantics.
Also, I am proposing that this "recursive collection
revision selection" only take place during the creation
of a deep-revision (baseline), not as a side effect of
putting a collection revision in a configuration.

Jim: What about Brad's comments didn't sound right to you?
What he said and what you said sound compatible to me.

Cheers,
Geoff

   From: Bradley.Sergeant@merant.com
   .
   Configurations need to map VersionedResource IDs to Revision IDs.
   Paths can change over time.  IDs must not change over time.  By
   sticking to IDs in configurations you allow configurations maintain
   their consistency, even while the path names change. 

   From:     jamsden@us.ibm.com at SMTPPOST
   .
   This doesn't sound quite right, so maybe we should be sure we're
   talking about the same thing. A revision of a collection does define
   the member names otherwise collections wouldn't specify
   namespaces.  When a collection is placed in a configuration, the
   binding of the collection members to particular revisions is done. If
   one of those members is a collection, bindings of its members must
   also be done. So the original namespace is maintained as long as the
   server/workspace maps a URL to the collection placed in the
   configuration (to establish the namespace).
   .
   If the path needs to change, then the collections must be checked out
   and their members moved or rebound. Then a new configuration would
   need to be created to snapshot the new state. The old configuration
   and namespace would still work.

   From: Bradley.Sergeant@merant.com
   .
   What you said sounds right to me (except the part indicating what I
   said doesn't sound right (:-).
   .
   The configuration is mapping the Collection's Versioned Resource ID to
   the appropriate Revision ID.  The Revision of the Collection maps the
   member name to its Versioned Resource.  To change a member name
   requires the user to checkout the collection, make the change, and
   check it in.
   .
   It is important that configurations not use names to identify
   Versioned Resources, that's what collections do.  The mapping defined
   by Configurations must be independent of changes to the names of items
   they contain.  On the other hand, by selecting the revision of a
   Collection the Configuration is indirectly determining the names of
   the members.  See the point?