W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Deletion semantics for versioning metadata

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 20 Nov 2000 22:07:41 -0500 (EST)
Message-Id: <200011210307.WAA20891@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   On Sun, Nov 19, 2000 at 01:08:03PM -0500, Geoffrey M. Clemm wrote:
   > Greg has asked that we clarify the results of deleting things
   > like working resources, versions, version histories, etc.
   > I believe it is sufficient for us to say that if a server allows you
   > to delete such a resource, that all the versioning properties of other
   > resources that refer to that resource should be updated to no longer
   > refer to the deleted resource (I'd probably enumerate those properties
   > to make sure there is no misunderstanding).

   It seems a bit more complicated than that. If you delete a version history,
   then I'd expect the corresponding selectors and versions to become
   non-controlled resources.

I think that's something we need to leave up to the server implementor,
since I don't think we will be able to agree on this.

   But even then, it seems that you could lose all the information on how to
   track down the available versions for a given resource.
   (of course, I'd expect most servers to just refuse deletion of versions and
    version histories, but the spec may not be able to make that assumption;
    hmm. I guess it could say "server defined")

Yes, that would be my choice.   I agree that most servers will simply
refuse to do it, so I wouldn't want to add any complexity to the spec
just to define something that is unlikely to be implemented.

   Mostly, I'm concerned with what deletion of a working resource and an
   activity means. For the former, I'd expect something like an UNCHECKOUT.

Yes.  I think you'll find that this follows from the rule that all
property references must be deleted, but I'll make it explicit just
to make sure there is no confusion.

   an activity, I'd expect a full rollback of all associated checked-out
   resources. Specifically, let's say that I have an activity with 10 working
   resources associated with it; I'd like to do one of two things to that
   activity: CHECKIN or DELETE, corresponding to "commit" or "rollback". After
   either of those operations, the activity and all working resources are gone.

We'll probably get some pushback there from repositories for which
activities are optional.  For them, deleting an activity would just
mean that you have checkouts that are not against an activity.
So I'd leave anything beyond "removing all references to the deleted
resource" as a server choice.  I certainly agree that we should *allow*
a server to delete associated working resources.

Received on Monday, 20 November 2000 22:08:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC