RE: Status code for creating lock-null resource

The more I think of this, the more confused I become.  Maybe that's not
unusual, but ...

"Jim Whitehead" <ejw@cse.ucsc.edu> wrote:
> 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.

I agree with all of this. (Despite Section 3 of RFC2518 that states clearly
that a null resource is a resource.)

I think that calling it "null resource" is very misleading since we agree
it is not a resource.  I'll use your "unmapped-URL" term for now to help
distinguish.

http://ces.ucsc.edu/bogus/bogus/bogus.html is an unmapped-URL, got it.

> A lock-null resource is a null resource that has been locked.

Or in the new phraseology, "a lock-null resource is an unmapped-URL that
has been locked".

Hmm, that doesn't sound right does it?  A resource is-a URL?

And not _all_ unmapped-URLs (in DAV compliant namespace) can be locked.
It seems that we need to augment "unmapped-URL" with "where the immediate
parent exists".

> Since a lock null resource has state, I would claim it is a
> resource. By the act of a client taking out a lock, they have
> likely made a mapping of a URL to a conceptual resource, and
> are int he process of fleshing out the computer representation
> of the conceptual resource.

Agreed.  Moving the server state of an 'unmapped-URL where the immediate
parent exists' from no resource to a resource should, IMHO, respond with
201 Created.

QED <g>

Tim

Received on Monday, 18 June 2001 05:39:03 UTC