Do states in a No-tag-list production apply to the parent?

I would like some clarification on the question of whether the state token
in a a no tag list production is to be applied to the parent collection of
a resource.

In my opinion, it should not apply.  

The spec leaves some room for interpretation on this question, which is why
I ask.

9.4.1 says
   If a method, due to the presence of a Depth or Destination header,
   is applied to multiple resources then the No-tag-list production
   MUST be applied to each resource the method is applied to.

To elaborate on why this is a problem.  Suppose I have collection C which
contains resource R. I lock resource R, obtaining token T, then I try to
DELETE R, passing token T in a no-tag-list production.\

Since I am deleting a member from C, the state of C is relevant to this
method, and must be checked.  (For example, if C were locked by some second
lock, the method would fail.)  But since the lock is on R, not C, C is
*not* in the state T.  If the no-tag-list production were applied to C (as
the parent of R) it would fail.  This seems undesirable.

Maybe this is what 9.4.1 is *trying* to say, but it is not clear.  It tells
me what resources the production MUST be applied to, but does not tell me
which ones it MUST NOT be applied to, ie. the parent.  Is the DELETE method
"applied to" the parent?  It affects the parent, but is it "applied to" it?

I would like a clearer statement in the spec.

It seems to me that it should NOT be applied to the parent, because

 1) if it is, then there's no way to delete a collection that is locked.
You have to use the no-tag production in this case, and as I show above,
this can't work.

 2) there is also no need for it.  If you need to pass a token for a lock
on the parent, you can pass it using the tagged production.  After all, you
really only need the no-tag prod when the method applies to a set of
resources ie when  operating recursively on a collection. 

Any objections to this interpretation?

Received on Thursday, 10 December 1998 18:46:43 UTC