W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: new proposed text for locking overview

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 8 Jul 2004 00:29:41 +0200
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF20B8041A.99B5331E-ONC1256ECA.007AAEC8-C1256ECA.007B931C@us.ibm.com>
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).


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 
Received on Wednesday, 7 July 2004 18:30:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC