RE: rfc2518bis-14: locking terminology

"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?"
 
[John] I still don't agree.  The basic question is if you copy a resource
has a lock, does the target resource have a lock (albeit with a different
lock-root).  The answer is "no" it doesn't, if the target is not under a
locked parent; that should be clearly stated somewhere.  Similarly a locked
resource that is MOVED, does it still have a lock?  The answer here is also
"no" it doesn't, if the target is not under a locked parent; this should
also be clearly stated somewhere.  Why not clear up ambiguity with
definitive statements?  Argue as you might, clearly there are those who
believe there is ambiguity, otherwise this language wouldn't have been
added.  BTW, this language, or something similar was in the previous 2518
spec., and I don't see a compelling reason to remove it now.
 
-John 





  _____  

From: Manfred Baedke [mailto:manfred.baedke@greenbytes.de] 
Sent: Thursday, March 16, 2006 10:25 AM
To: John Barone
Cc: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking terminology


John Barone wrote: 

"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 section 6.1.4.



Agreed that section 6.1 should define lock depth.


 
 
[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.



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.


 
Move/Copy behavior...
 
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.


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.

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?

Regards,
Manfred