Configurations, sets and collections

Jeff McAffer OTT (Jeff_McAffer@oti.com)
Mon, 19 Apr 1999 18:00:24 -0400 

From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org ('ietf-dav-versioning@w3.org')
Message-ID: <1999Apr19.175810.1250.1151130@otismtp.ott.oti.com>
Date: Mon, 19 Apr 1999 18:00:24 -0400
Subject: Configurations, sets and collections


(this got long but you may find it interesting...)

I have a proposal for the configuration problem which actually combines   
the two approaches discussed in today's conference call.

Consider the following simple structure in a particular workspace.  Shown   
are the human URL segments and the versioned resource (VRxx) to which the   
URLs map.
  /  (VR4)
    A/  (VR7)
      B/  (VR 6) 
        index.html  (VR 9)
    X/  (VR 2)
      cool.gif  (VR3)
    Y/  (VR1)
       ...

What this structure really implies is that VR4 (/) is a collection   
resource which has three named elements, A, X and Y where A => VR7, X =>   
VR2 and Y => VR1.  Similarly, VR7 is a collection which has one element   
such that B => VR6.  and so on.

Below is a description of the two proposals for configurations ("sets"   
and "collections") in terms of the above example.

SETS
====
The "Sets" proposal said that a configuration was a *set* of resource   
revisions.  A couple things to note:
 - revisions have a property which indicates their versioned-resource.
 - "setness" here is based on versioned-resource not revision.
   That is, there can only be one entry in the configuration
   for a particular versioned-resource.
 - As such, the "set" can be seen as a table where a key is a
   versioned-resource id and the corresponding value is a revision
   id.  A given key can only occur in a configuration once.

In the above example, a configuration encompassing A and X (but not /)   
would look something like this (where Rxx is a revision id).
 VR7 = R23
 VR6 = R3
 VR9 = R9
 VR2 = R12
 VR3 = R11
Because VR7 and VR2 are collections and collections map member names to   
versioned-resources, the namespace *below* A and X are preserved.  That   
is, the *relative* path B/index.htm still exists if you can get to VR7.   
 The configuration roots can be relocated by "mounting" them at some   
point in the user URL space (e.g., putting VR7 at /foo/A).

There is a problem though.  Because VR7 (A) and VR2 (X) are local roots,   
they have no containing collection within the configuration and their   
names are not preserved.  So when I mount the configuration in URL space,   
I have to somehow come up with names for these (potentially numerous)   
root versioned-resources.  For example, how did I know to use 'A' when   
mounting VR7 at /foo/A in my example above?  This seems like the 80% case   
to me and yet there is no place in the system to put this information.

One solution is to logically (if not physically) put these "roots" into a   
"root-collection" which maintains the namespace for VR7 and VR2 (A and X   
respectively).  I'm not sure if this is DAV server functionality or   
something that clients do on their own.  I hope it is the former so that   
it is standardized and interop between tools is enabled.  Opinions?

BTW, it was proposed that new "set" protocol be added.  Would it be   
reasonable to use regular collection protocol and give the   
versioned-resource id as the name and the revision-id as the element when   
putting something into a configuration?  This avoids having to add   
methods etc to the protocol.

COLLECTIONS
===========

The "Collections" proposal said that a configuration was a collection of   
revision ids.  Being a collection means there must be member names.  I   
was confused on this and did not really understand what these names would   
be.  One choice was that they were autogen'd/random.  In this case, case   
the names don't mean anything so why bother? Just to satisfy some API?

Another choice (as I understood it) was that the names were the URL   
fragments relative to the roots.  Note that in either case, the values in   
the collection are the complete revision ids (including the   
versioned-resource id) of the resource revision in the config.  For the   
example above, the configuration is:
 A = VR7.R23
 A/B = VR6.R3
 A/B/index.html = VR9.R9
 X = VR2.R12
 X/cool.gif = VR3.R11
Note that the names of VR7 and VR2 are maintained.  Unfortunately, there   
are problems.  First the information is redundant.  The namespace,   
exclusive of the names A and X, is maintained by the   
versioned-collections themselves.  This leads to the problem that if I   
rename B in A, I have to go and change all the entries in the   
configuration.  If A is high up in a large configuration, this is   
expensive.  In the Sets example, you only have to change the revision of   
VR7.  It does however allow you to maintain the collection protocol for   
configurations.

SUMMARY
=======
Overall I vote for Sets with the ability to maintain root names in some   
standard way.  I do not have to use then when mounting a configuration   
but it sure would be nice to have that starting point.  If we are really   
hot about putting individual revisions into a configuration, use the   
versioned-resoruce id as the name and the revision-id as the value on a   
regular collection put operation.

BTW, we still need to talk more about "required/needed configurations".