RE: Collections, Resourcetype and Hierarchy in WebDAV

See below.

> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Sunday, December 27, 1998 3:55 PM
> To: Yaron Goland; WEBDAV WG
> Subject: RE: Collections, Resourcetype and Hierarchy in WebDAV
> 
> 
> > 1 Why Did WebDAV Decide that the HTTP URL Namespace is a Hierarchy?
> 
> I don't find the answer to this question very satisfying.
> It sounds like "the working group decided to do this
> because the working group decided to do this".
> 

Actually the WG decided to do this because they felt they needed it.

> > A typical HTTP URL looks like 
> http://server.com/name1/name2/name3. The
> > HTTP/1.1 specification never defined what the "/" really meant.
> > Did the "/"s have any meaning or were they just decoration to
> > help people remember where they put their resources? This was
> > one of the very first problems the WebDAV Working Group 
> (WG) had to face.
> 
> It's not clear why this problem was 'faced' by the working group.
> I mean, does the "1" in "name1" have any meaning, or is it just
> decoration? Why is this a problem?
> 

As I said in the paper, the WG felt that defining "/" to have a meaning, as
is done in file systems, was a useful thing.

> > Most of the WG had the very definite idea that WebDAV should
> > provide at least file system level functionality.
> 
> The problem is that the notion of 'file system level functionality'
> is pretty fuzzy, and 'at least' is even fuzzier (which file system?).
> Even though most of the WG might agree on a general principle, it
> isn't clear that this is a good decision process for deciding on
> a particular feature. In particular, it might be desirable to have
> a client be able to determine at least one collection that contains
> a given resource, if one is known, but it's not at at clear that
> the requirement that there be a single canonical parent that contains
> any resource corresponds to 'at least file system level 
> functionality'.
> In fact, we have lots of counterexamples of file systems for which
> this requirement doesn't match at all (just to pick one example,
> unix file systems which allow 'hard links').
> 

Actually, I specifically pointed out links as an exception that the WG
decided to deal with separately. Given that UNIX supports the identical
hierarchical structure to WebDAV it was felt that we could also add hard
links later, UNIX did.

> 
> > document management types who didn't really use file systems, they
> > understood that file systems were the single most common form of
> > storage on the planet. Matching file system functionality 
> meant providing
> at
> > least the possibility of supporting a hierarchical namespace.
> 
> But WebDAV doesn't "match" file system functionality in this
> regard. Rather, WebDAV chose to emulate a very restricted
> model of file system, and require this model for all of
> the WebDAV servers.
> 

What do we fail to match?

> > So the WG decided that the "/"s could represent a hierarchical
> > namespace and that it was WebDAV's job to provide the tools to
> > create and maintain that hierarchy if the client/server choose
> > to make it hierarchical.
> 
> It's exactly this problem, that the client and server mutually
> have to agree on the semantics, that makes this a serious problem
> for WebDAV interoperability. Clients that are written to assume
> DOS-like file systems will not interoperate with other storage systems
> that don't have such restrictive semantics.
> 
> Larry
> 

An example of where WebDAV fails would be useful.

Received on Monday, 28 December 1998 16:50:39 UTC