W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

Re: RE: Collections

From: Del Jensen <dcjensen@novell.com>
Date: Fri, 19 Sep 1997 14:44:09 -0600
Message-Id: <s422905c.086@novell.com>
To: johnt@cgocable.net, ejw@ics.uci.edu
Cc: w3c-dist-auth@w3.org
What kind of language ("MUST" or "SHOULD") most effectively promotes interoperability in this case?  Why use the protocol if you are going to ignore the object model?


>>> Jim Whitehead <ejw@ics.uci.edu> 09/19/97 11:54AM >>>

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 
> 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 
> where C is not part of the collection, simply part of the URL space. 
> 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
Received on Friday, 19 September 1997 16:47:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:11 UTC