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

Re: new proposed text for locking overview

From: Elias Sinderson <elias@cse.ucsc.edu>
Date: Tue, 06 Jul 2004 13:21:26 -0700
Message-ID: <40EB09C6.3090604@cse.ucsc.edu>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Jason Crawford <ccjason@us.ibm.com>, WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>

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


Cheers,
Elias
Received on Tuesday, 6 July 2004 16:22:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT