John Barone wrote:
Agreed that section 6.1 should define lock depth.
"My main point here is the use of undefined
terminology, though I indeed think that section 6.1 will be perfectly
clear on the distinction between a depth 0 and a depth infinity lock as
soon as 6.1.4 uses the term 'member' instead of 'internal member'. 7.4
contains nothing new, and a list of special cases can never be as
concise as the general principle itself. "
[John] OK, I can see
that; however section 6.1.4 does not make the distinction between depth
0 and depth infinity locks. This section needs to be cleaned up to
make that distinction, and spell out the exact bahavior in both cases.
Maybe combining what's in section 7. bullet 2 and what's currently in
The target URI of a lock request will never be a collection, but the
URI of a collection. An URI is an URI and a resource is a resource. As
defined in 6.1, resources can be locked. URIs can't.
[John] If the root of a lock is
a collection, it's important to make clear
that that collection is locked, along with all it's decendents. I think
this statement should stay (but perhaps reworded to be more precise).
My point here is that URIs cannot be locked. Resources can be locked,
but the root of the lock is not a resource.
[John] If the target URI for a depth infinity
lock request is a collection, the collection IS most certainly locked.
But to your point, if the language in section 6.1.x is cleaned up, this
entire section can be removed.
Well, if the spec does not define what it means to move a property,
then it should either correct this or stop to use this terminology.
Well, copying locks is as
undefined as lock duplication
How could one think that a lock could be moved if it is not defined
what this could mean?
... by the same token, what does it mean
to duplicate or move live or dead properties; those operations aren't
defined either for properties, and yet you MUST/SHOULD do it. I don't
see the harm here, in fact I think it's a very good idea to explicitly
state this in the spec. to remove ambiguity. I think the copy/move
MUST NOT statements should be kept either in a 7.x section, or wrapped
into a revised 6.1.4 section.
Section 6.1 defines what a lock is. This is done by giving a set of
"axioms", propositions using the term 'lock' which are true by
convention. It should be possible to read the spec without the
slightest idea what a lock could be. Let us assume that we have no such
idea and read section 6.1. Then we have an understanding of what a lock
is, but we would be very surprised if someone spoke of 'moving locks'.
We would say something like: "Hey, wait, how can you move it if it does
not even have a location?".
If one thinks that it makes sense to move a lock, he simply has an
understanding of the term 'lock' that does not match the definitions in
this specification. If the specification never mentioned 'moving
locks', why would any reader think that this term even had a meaning?