Thanks for the explanation. By "state" I just meant "the set of
bindings", but I see how a non-clairvoyant reader would not know
this. Just to confirm that I understood your point, would this
rewording be acceptable:
"A successful DELETE removes the specified binding from the specified
collection, but (whether it succeeds or fails) MUST NOT remove any
other other bindings from the specified collection or any other collection."
Cheers,
Geoff
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
In message <10001271914.AA29510@tantalum>, "Geoffrey M. Clemm" writes:
> >"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.)
A protocol requires that the externally visible behavior of the
component match that expected by the protocol. The way you phrased
it was specifying the state within the collection component rather
than what was visible to other components. Consider, for example,
that a hierarchical database implementation of collections might
have dual-linked relations between sister collections, and thus
deletion of one collection would have to effect another collection.
The point being that we don't have to require anything beyond what
the protocol means -- specifying anything beyond that is just overkill
and tends to limit implementations unnecessarily.
....Roy