Re: Support for non-DAV collections

Lisa Dusseault wrote:
> On Sat, 09 Jul 2005 09:40:35 -0700, Julian Reschke 
> <julian.reschke@gmx.de>  wrote:
> 
>>
>> Lisa Dusseault wrote:
>>
>>> It depends on whether we're going for Draft Standard or not -- and 
>>> it  was  my understanding that Ted is keeping the WG open so we can 
>>> bring  WebDAV to  Draft Standard.  To go to Draft Standard, we need 
>>> to take a  Proposed  Standard and remove the options that aren't 
>>> implemented,  interoperable and  tested 2x2.
>>
>>
>> Yes. Every server that supports collections as WebDAV compliant  
>> resources already supports this feature. And every client that issues 
>> a  PROPFIND without using other WebDAV methods already uses it. I'm 
>> not  sure what kind of additional test you're looking for.
> 
> 
> That's not how I read it.  I understood that paragraph as saying that a  
> server could call something a collection (using the resourcetype 
> property)  but have it be non-WebDAV-compliant resources.  In fact "not 
> be WebDAV  compliant" is in the first sentence.  So that's why I asked 
> if anybody had  implemented non-WebDAV-compliant resources that still 
> had the  DAV:collection element in the DAV:resourcetype property.  I can 

What the spec says is that if a server has something that is a 
collection, but if the collection (or it's members) are not 
DAV-1-compliant resources, the server still can return a 
DAV:resourcetype of DAV:collection. That is, to be a DAV:collection is a 
feature that is ortogonal to other WebDAV features.

BTW: this implies that the collection supports PROPFIND, otherwise 
there'd be no way to return a resource type.

I think it's a very good approach, because it offers servers to pick one 
specific WebDAV feature (collection) without having to reach full WebDAV 
compliance.

In general, this is how many features in WebDAV work. For instance, a 
server can go ahead and implement one single WebDAV method (for 
instance, MKCOL), and nothing else. As long as it claims WebDAV 
compliance (through the DAV response header), this is just fine. So 
removing the sentence doesn't really change what the spec defines; it 
just makes one implementation option less obvious -- can you give a 
specific example where removing the statement would change *any* of the 
current interop requirements?

> imagine  how one might use this -- for example, it might show up in its 
> parent as a  collection yet not itself support direct PROPFIND requests 
> -- but I am  unaware of any implementations.

This is what 5.2, paragraph 4 explicitly states 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.5.2.p.4>):

"Collection resources MAY list the URLs of non-WebDAV compliant children 
in the HTTP URL namespace hierarchy as internal members but are not 
required to do so. For example, if the resource with URL 
http://foo.com/bar/blah is not WebDAV compliant and the URL 
http://foo.com/bar/ identifies a collection then URL 
http://foo.com/bar/blah may or may not be an internal member of the 
collection with URL http://foo.com/bar/."

 > ...


Best regards, Julian

Received on Sunday, 10 July 2005 08:44:16 UTC