This rewording is fine with me. Cheers, Geoff Lisa wrote on 12/29/2005 06:35:36 PM: > > Looking carefully at the text of GULP from > <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ > 0177.html>: > > - If a request would modify the content for a locked resource, a dead > property of a locked resource, a live property that is defined to be > lockable for a locked resource, or an internal member URI of a > locked collection, the request MUST fail unless the lock-token for > that lock is submitted in the request. An internal member URI > of a collection is considered to be modified if it is added, > removed, or identifies a different resource. > > > I see two problems with this paragraph > - The content of a resource is not defined anywhere. Should this be > rewritten as "any variant" in order to consistently use RFC2616 > terminology? > - The phrase "a live property that is defined to be lockable" implies > that we define properties to be lockable, but we don't. Any > suggestions for fixing this? > > One simplifying possibility is that if the request would modify *any* > live property, the lock token is required. However I'm concerned that > there are some calculated live properties for which that would be > undesirable. For example, if a resource had a live property called > "last-copied-to", and a COPY of that locked resource to some other > location caused the server to change the value of that live property to > the copy destination, then we wouldn't want to require the lock-token > of the source just because of that live property. > > As a strawman, here's a proposed rewrite of the para, including minor > rewording/rearrangement for readability: > > "A lock-token must be submitted in a request if that request would > modify any of the following aspects of a locked resource: > - any variant, > - any dead property, > - any live property (unless otherwise specified for that property), > - for a collection, an internal member URI. > An internal member URI of a collection is considered to be modified > if it is added, removed, or identifies a different resource." > > Lisa > >Received on Friday, 30 December 2005 01:08:11 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT