Re: new proposed text for locking overview

I agree with Elias (and Julian).  In particular, I agree
that Julian's usage of the term resource exactly follows the
definition and recommended usage in RFC 2396. 

In general, I strongly support the proposed text for the locking
overview as it is currently written (it is a very significant
improvement over what appears in 2518 or 2518bis).

Cheers,
Geoff

Elias wrote on 07/06/2004 10:21:26 PM:
> >  Jason Crawford:
> >
> >> ...  I don't like us calling a lock a resource.

> Julian Reshke:
> > I expected pushback on that wording; but I think it really makes 
> > things clearer. Anything that has a URI *is* a resource (as per 
> > RFC2396 definition). Saying that it is a resource with internal state 
> > makes talking about it a lot simpler. So can you explain *why* you 
> > don't like that terminology? 
 
> Elias Sinderson:
> Initially I also had a negative reaction to calling a lock a resource, 
> since I generally use that word to refer to something that one can GET, 
> PUT, PROPPATCH, etc. However, after reviewing RFC2396 to refresh my 
> conceptual understanding of URIs vs. URLs, I have less of a reservation 
> on using the term as Julian has for locks. A significant turning point 
> in my feeling on this was in reading the explicitly referenced 
> definition of a resource in section 1.1 of RFC2396:
> 
>       Resource
>          A resource can be anything that has identity.  Familiar
>          examples include an electronic document, an image, a service
>          (e.g., "today's weather report for Los Angeles"), and a
>          collection of other resources.  Not all resources are network
>          "retrievable" [...]
> 
> In short, while my initial reaction was on par with Jasons', I'm okay 
> with the wording - especially since it seems to make things clearer and 
> a clearer specification will only lead to better implementations in the 
> long run (even if the implementors have to reference RFC2396 
themselves)...