Subject: RE: Status code for creating lock-null resource

From: [email-masked]
Date: Mon, 18 Jun 2001 10:36:52 +0100

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

"Jim Whitehead" <[email-masked]> 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

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 20 Jun 2001 16:49:45 -0700

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

When that was written, I had a different model in my head.  In that model, a
null resource was in fact a resource, but all this resource ever did was
respond with "404" to everything.  Pretty dull resource.

But, I now think the "unmapped URL" is much closer to the idea I wanted to
capture by this term.

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

Now a lock-null resource would be a *resource* with:

* null (or undefined, take your pick) state
* properties as defined in 7.4

That is, by reserving the name, you have explicitly created a mapping
between a URL and some abstraction, whose state will be fleshed out later.

> It seems that we need to augment "unmapped-URL" with "where the immediate

Good point.

> parent exists' from no resource to a resource should, IMHO, respond with

This makes sense to me. My concern is that it would still be nice for the
first PUT after a lock-null is created to also return a 201.

- Jim