RE: empty resources

Again, my apologies for the slow response.  These are excellent questions, 
thank you for posting them!

On Thursday, March 12, 1998 8:52 AM, Jim Davis [SMTP:jdavis@parc.xerox.com] 
wrote:
> At 06:33 PM 3/10/98 PST, Jim Whitehead wrote:
> >> ...can I do a PROPPATCH on a URI for an empty resource?...
>
> >We don't explicitly permit this operation in the -07 spec. because if 
you
> >create properties on a null resource, that resource becomes non-null, 
and
> >then has a body as well.  This creates an awkward situation where there 
is
> >a non-null resource without a content type.  To set properties on a null 
> >resource, first do a PUT with a Content-Type header and a zero length 
body,
> >creating a resource with a known content type, and an empty body. Then,
> >perform a PROPPATCH on this empty resource.
>
> I would like you to clarify this, so there is no doubt.  It should be
> either explicitly forbidden, explicitly allowed ('may'), or explicitly
> required.  At the very least, it should explicitly be left undefined, 
which
> would serve as a warning to the cautious not to rely upon it.
>
> I had been assuming for weeks that it *was* supported, because LOCK seems
> to rely on it. My server supports it, and I've written client code that
> relies on it.  Naturally I'll change my code to comply with the standard,
> but I want the standard to be clear on the point.
>
> So.  Are you saying that a PROPPATCH on a null resource MUST fail (with a
> 404)?

Yes.  We need to add language to Section 7.2.1 to explicitly state that a 
404 response MUST be returned after performing a PROPPATCH on a null 
resource.

It is my understanding that Yaron is also working on a definition of a null 
resource for inclusion in the draft to help avoid confusion about what 
constitutes a null resource.  I believe the definition will be mostly 
operational to avoid some of the definitional difficulties I mentioned in a 
previous email.


> I would be the first to admint that making such support mandatory would 
be
> a burden on implementors, at least those implementing on a file system. 
 It
> was a pain for me, that's for sure.

Sounds like a good reason not to have it in the spec. :-)

> Another clarifiction question:
>
> 6.3 says that a write lock on a null resource makes the resource act "in
> all ways as a null resource, except that it MUST respond to a PROPFIND
> request".  This raises two questions

I just knew questions like this were lurking beneath this seemingly 
innocent-looking feature :-)

>  1.  What about the collection that contains it?  In particular does the
> null resource appear in its list of members if one does a PROPFIND of
> non-zero Depth?

Yes, a locked, null resource does appear in the list of members if one does 
a PROPFIND of non-zero depth on a parent resource, to provide a discovery 
mechanism to find locked, null resources.  Section 6.3 will be amended to 
explicitly mention this behavior.

>  2.  What about PROPPATCH?  Does that work?

No, because if you were allowed to PROPPATCH, this would add state to the 
resource beyond that state automatically created by the LOCK.  This 
non-LOCK-created state should presumably be kept around after an UNLOCK, 
which is at odds with the current definition that an UNLOCK of a locked 
null resource reverts the resource back to its null state.

> Oh, and I know it's picky, but shouldn't UNLOCK also be included in the
> list of requests it must support?

Yes.

> yours in seeking clarity

Hopefully yours in providing clarity.

- Jim

Received on Friday, 20 March 1998 17:45:24 UTC