W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Status code for creating lock-null resource

From: Hall, Shaun <Shaun.Hall@gbr.xerox.com>
Date: Mon, 18 Jun 2001 09:41:02 +0100
Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875C2@gbrwgcms03.wgc.gbr.xerox.com>
To: WebDAV WG <w3c-dist-auth@w3.org>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: 15 June 2001 19:51
> To: WebDAV WG
> Subject: RE: Status code for creating lock-null resource

> There is a difference between a "null" resource, and a "lock 
> null" resource.
> The definition of a "null" resource, as given in Section 3, 
> is correct. Lock
> null resources are defined in Section 7.4. A null resource 
> does not belong
> to its parent collection, and does not respond to UNLOCK. 
> Perhaps a better
> way to express this concept is that what we termed a "null 
> resource" is
> really an "unmapped URL". That is, the URL is not mapped to a 
> resource. This
> avoids the philosophical question of "is a null resource a 
> resource"? By
> calling it an unmapped URL, a "null resource" is clearly not 
> a resource.

Agreed on all of Jims points. I like the point about "URL is not mapped to a
resource". Maybe it could be included in the revised RFC as it could make
things clearer for some people ?

> A lock-null resource is a null resource that has been locked. 
>  A lock null
> resource has diferent properties that a null resource. 
> Specifically, it has
> at least the lock discovery properties, and it is a member of 
> its parent's
> collection.


IMHO, null resources have no properties. After all, they don't map to any
resource within the server, can't do a PROPFIND on them etc. Is my
interpretation wrong ?

Just a reminder, LNRs have *all* the mandatory DAV properties (RFC 2518 sec
7.4), though as spec states, most will have no value (except lock
properties). One can legitimately perform a PROPFIND on a LNR and retrieve a
DAV:* property.


Shaun Hall
Xerox Europe
Received on Monday, 18 June 2001 04:48:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC