- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 27 Jan 2000 14:14:50 -0500
- To: w3c-dist-auth@w3.org
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> In message <10001271756.AA29444@tantalum>, "Geoffrey M. Clemm" writes: >I agree with Judy's description of what we want to achieve by saying >DELETE is atomic. Another way of phrasing it is that avoids the word >"atomic" is to say: > >"A DELETE modifies the state of the collection resource containing the >specified binding (namely, by deleting that binding), but MUST NOT >modify the state of any other collection resource as a side effect." No, that is a requirement on the implementation, not the protocol. Why don't you just use the two paragraphs that Judy listed? I like Judy's two paragraphs, so that's fine with me. Just for interests sake, since my rewording was intended to be just state the key point from Judy's two paragraphs, what was wrong with it? Doesn't a protocol always defines requirements on the implementation? (I'm not disagreeing with you, I just didn't understand your point.) >>1. DELETE removes a single binding. It does not remove all the bindings to >>a resource, only the one identified by the Request-URI. If it happens to be >>the last binding, then what happens about garbage collection of either >>content or properties is outside the scope of the spec. DELETE is just >>about removing the binding. > >>2. In the case where the binding is to a collection, DELETE still means only >>remove the binding to that collection. It is not acceptable to walk the >>tree deleting bindings to descendents of that collection. This would have >>disastrous consequences in an environment with multiple bindings to >>resources. To resurrect an example of Jason's: This has nothing to do with "atomicity". I agree. The term "atomicity" should not be used in this context. It does, however, raise a problem in that removing the last binding to a non-empty collection might be unacceptable to the server. This second case should allow the server to report an informative error if it requires that the collection be empty first (this would depend on the nature of the colection resource, not on some aspect of the protocol). Good point. An appropriate error status should be defined. Cheers, Geoff
Received on Thursday, 27 January 2000 14:14:52 UTC