Next message: Geoffrey M. Clemm: "nested DAV:rsr-or and DAV:rsr-merge"
Date: Wed, 5 Jan 2000 13:21:24 -0500
Message-Id: <10001051821.AA18439@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Removing the "single line of descent" restriction on activities
Currently, an activity without a DAV:needed-activities property must select
revisions in a single line of descent, while one with a DAV:needed-activities
property does not. (The DAV:needed-activities property enumerates the
sub-activities that contribute to the logical change of the activity).
I believe that this effectively makes the "single line of descent"
restriction pointless, since clients will need to deal with activities
that do *not* select a single line of descent (since any activity might
have or be given a DAV:needed-activities property).
I see several alternatives:
(0) ignore this issue and leave things as they are now
(1) remove the DAV:needed-activities property
(2) extend the "single line of descent" to apply to the union of
versions in an activity and its needed-activities
(3) remove the "single line of descent" requirement
My thoughts on these alternatives are:
(0) I don't like this alternative (clearly, or I wouldn't have bothered
to send out this message :-). I believe this will be a significant cause
of error for clients and servers that don't realize that single-line-of-descent
does not always hold.
(1) I think the ability to compose activities out of other future, current,
or prior activities is too important to give up except as the very last resort.
(2) Since different activities will be worked on independently, I think
it will be computationally infeasible to detect when single line of descent
is violated for multiple activities being changed in distinct workspaces.
(3) I think this is the right way to go. This doesn't actually change
anything from a client's perspective, but ensures that clients don't try
to incorrectly take advantage of a constraint that does not in general
hold.
As always, silence will be taken as permission to make this change to
the next draft of the spec, but will not imply that you will not object
at some later date (:-).
Cheers,
Geoff