RE: "Closing" an activity

   From: Roy Seto [mailto:Roy.Seto@oracle.com]

   I'm following up on this discussion from 

 
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001OctDec/0021.html

   in a separate thread. At this point, I'm just looking for
   clarification whether my interpretation of the spec is accurate.

   I wrote:

      - Activity feature: Is there an interoperable way to "close" an
 activity (that is, prevent any more checkouts or checkins in
 that activity)? Followup: if not, how much demand would there
 be for standardizing this concept?

   Geoff replied:

 I suggest we should soon start a follow-on "change request"
 working group (we could start under the auspices of the WebDAV
 working group).  In particular, we would then discuss various
 states that an activity could be in, and how to standardize
 transitions between those states (is PROPPATCH enough?).
 Minimally, we could decide on some standard XML element for
 the state field of an activity, and a few "standard" state
 values.  Perhaps a BOF at the Dec IETF?

   Continuing this discussion, Geoff's proposal sounds reasonable to
   me, though I'm not sure I have any activity states to propose
   beyond "closed" and "not closed."

"new" "open" "scheduled" "active" "fixed" "no-plan-to-fix"
"unreproducible" ...

   To validate my understanding of the spec, it seems to me that there
   is currently no interoperable way to prevent checkouts and checkins
   from occurring in an activity.

That is correct.  We would need to introduce something like the
"state" property that you propose to get this functionality.
I believe that is significantly superior to trying to use
LOCK functionality, because there is no need for the complexity
added by requiring a lock token.

   In particular, RFC 2518 write locks on the activity resource don't
   do this because RFC 2518 Section 9.3 says:

      While those without a write lock may not alter a property on a
      resource it is still possible for the values of live properties
      to change, even while locked, due to the requirements of their
      schemas.  Only dead properties and live properties defined to
      respect locks are guaranteed not to change while write locked.

   So taking a write lock on the activity resource does not restrict
   changes on that activity's DAV:activity-version-set or
   DAV:activity-checkout-set property values.

   Also, draft-ietf-webdav-acl-06 Section 3.2 says 

      The [DAV:write] privilege controls methods that modify the
      content, dead properties, or (in the case of a collection)
      membership of a resource, such as PUT or PROPPATCH.

   So restricting the DAV:write privilege in an activity resource's
   DAV:acl property doesn't restrict changes in that activity's
   DAV:activity-version-set or DAV:activity-checkout-set either.

   Is my understanding correct?

Yes.  We could of course introduce a special privilege that controls
changing the DAV:activity-version-set or DAV:activity-checkout-set,
but I believe the activity state field is better for this purpose.

Cheers,
Geoff

Received on Sunday, 7 October 2001 19:10:07 UTC