RE: Collections

John Turner writes:
> If the the whole hierarchy is not treated as a collection, you leave open
> the possibility of some user confusion.  The namespaces of the URLs and 
the
> collections overlap, but are not identical.  For example, if you have
> collection /A you could have /A/B where B is an internal reference and 
/A/C
> where C is not part of the collection, simply part of the URL space. 
 This
> might be useful, but it will certainly be confusing.

My assumption has always been that any collection-like object in a DAV 
server's namespace should be modeled using a WebDAV collection -- an 
assumption so deeply ingrained none of the authors ever thought it was 
worth writing down. (Bzzt! :-)

I agree a requirement should go into the specification stating that 
collection-like objects SHOULD be WebDAV collections.  My question is 
whether this should be a MUST or a SHOULD requirement.

I'm leaning towards SHOULD because there are cases where part of a server's 
namespace is computed, and hence can be potentially infinite.  For example, 
if a server has a part of its namespace which acts as input to a cgi script 
(e.g., http://www.foo.org/finger-script/cgi-bin/user@host) what should 
INDEX return for the /cgi-bin/ collection if there is a MUST requirement?

On the other hand, if it was a MUST requirement, there could be language 
added which states that a server is not required to expose every member of 
a collection where the membership depends on the current request.  Although 
I'm unsure what the best way would be to express this, or whether this 
causes more problems than it solves.

- Jim