Re: IETF Versioning Meetings

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 10 Mar 1999 12:12:25 -0500 

Date: Wed, 10 Mar 1999 12:12:25 -0500
Message-Id: <9903101712.AA12625@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@hunchuen.crystaliz.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <00b001be6b12$7af59210$d0acddcf@yokohama.crystaliz.com>
Subject: Re: IETF Versioning Meetings

   From: "Sankar Virdhagriswaran" <sv@hunchuen.crystaliz.com>

   At the very least, I would hope that the current design will not make it
   hard to implement nested activities.

That is the case (i.e. nested activities just require an additional
"parent-activities" property for an activity).  The semantic affect
of nested activities would be that if a parent-activity is specified
in a revision-selection-rule, all child activities of that activity
are implicitly selected as well.  This doesn't require any additional
protocol support.

   How do <revision> selection
   rules interact with the proposal for URNs.

For simple revision-selection-rules (like activity, label, and
configuration based rules), there is no interaction (versioned resource
URL's or URN's do not appear in the rules).

There are some "scoped" revision-selection-rules that some servers
currently support, that apply a given rule clause to only a subset
of the versioned-resources.  This scoping could be in terms of the
proposed URN's or in terms of the URL's, or both.  It is likely that
we won't define these scoped rsr clauses in the first draft of the
spec, but a server is free to make this kind of extension.

   The reason I ask is again to see if the model I have in my mind will work. I
   see version selection happening because of default or explicit rules of the
   workspace (as proposed) or by user selection of 'names'. From a cursory
   understanding of the proposal for URNs that was recently sent out, I thought
   it allowed for user selection based on 'names'. Am I hoplessly confused?

Rather than talk about URL's and URN's, let's talk about types of resources.
There is a versioned-resource.  This is what you get after you put
a versionable resource under version control.  For versioning systems
that support a "repository" for versioned resource history, the 
versioned-resource is actually just a special kind of reference to a
"history resource" (that stores all the revisions etc. for that versioned
resource).

The versioned-resource always has a URL.  I have proposed that the
history resource have a URN.  My initial proposal was that these history
resource URN's be "locatable".  After the Monday discussion, I have agreed
to try to revise that to say "if you have a handle (e.g. a URL to)
a "repository", you can map that URN into a real resource".  (I haven't
had a chance to write that up yet).

So although you can get any revision from a history resource (by looking
at certain properties), the normal way of getting a revision is to take
the URL of a versioned resource, and specify a "Version-Name" or
"Workspace" header if you want anything other than the "default" revision.

   >I believe the answer is "yes", but if you have a dependency conflict model
   >in mind, please send it in for consideration.  The main reason that we have
   >not dealt with dependency conflicts is that there seems to be very little
   >commonality in servers today that we could capture in a protocol.

   I think you are right w.r.to commonality in servers today. However, it does
   not stop me from trying ;-). The general idea is to have a set of conditions
   that need to be met before a 'change' can be successfully applied (change
   and compound change are the same from this perspective). The conditions
   assert states in which items need to be for success. Different policy
   mechanisms can then be implemented to resolve conflicts that arise when a
   change is applied. The kind of dependency that I described in the example is
   one 'policy' that makes sure that 'read-write' conflicts are captured by the
   system. In parallel development with nested activities, this sort of
   dependency becomes key to manage. There are other policies that one could
   think of. I hope this all makes sense even though it is pretty abstract.

Since the conflicts report is an XML document, you should be able to extend
it to handle more specialized forms of conflicts supported by a particular
server.  Does this cover the use cases of interest?

Cheers,
Geoff