- From: Elias Sinderson <elias@cse.ucsc.edu>
- Date: Tue, 06 Jul 2004 13:21:26 -0700
- 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 UTC