- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 20 Nov 2000 12:36:15 -0500
- To: ietf-dav-versioning@w3.org
Ooops. I answered a totally different question than Tim asked. In particular, I answered the question "Is atomic checkin of the checkouts against an activity a SHOULD or a MUST". For that, I said "SHOULD". But the question he *asked* was, "Should the property updates be atomic with the delete". For that I say MUST. A dangling reference introduces the possibility that the reference will mistakenly be later bound to a different resource, which violates the semantics of those properties. Internally, an implementation can create dangling references, but the protocol should require that it detect such dangling references and strip them out before returning the property value. Cheers, Geoff -----Original Message----- From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] Sent: Monday, November 20, 2000 8:48 AM To: ietf-dav-versioning@w3.org Subject: Re: Deletion semantics for versioning metadata I believe it should be a SHOULD. There are a variety of versioning repositories that do not provide atomic group checkin behavior, and it is a reasonable server value-add to guarantee atomic behavior. A client can simply report the error, so it doesn't significantly complicate client implementations. Cheers, Geoff From: Tim_Ellison@uk.ibm.com Date: Mon, 20 Nov 2000 11:30:16 +0000 Is that 'should' a SHOULD or a MUST? There are likely servers that cannot achieve an 'atomic delete with multiple resource property updates'. Tim "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 2000-11-19 06:08:03 PM Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org cc: Subject: Deletion semantics for versioning metadata 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). Any objections? Cheers, Geoff
Received on Monday, 20 November 2000 12:37:28 UTC