RE: Clarification of URI vs. resource

The basis for the decision was a recognition that the majority of clients
who were likely to use WebDAV needed guarantees of a hierarchical namespace
because they did not have the capability, nor did they wish to develop the
capability, to display non-hierarchical namespaces. Recognizing that
standards never lead but always follow, the WebDAV working group obtained
consensus on the design principal that WebDAV would require namespace
consistency in those parts of the namespace that only contained WebDAV
resources. 

A second argument in favor of this decision was the realization that meeting
Ted Hardy's design principal that "I won't execute a command unless I know
what the result will be" we would have had to muck up DAV with extra gunk to
allow clients to demand namespace consistency or have the method fail. This
caused interoperability issues since it meant that any arbitrary WebDAV
client would not be able to effectively interoperate with an arbitrary
WebDAV server since the majority of WebDAV clients would always demand
namespace consistency.

A third argument in favor of this decision was the realization that the
absence of the consistency requirement would have required the working group
to spend a bunch of time essentially inventing "search" to allow clients to
figure out exactly which resources in the namespace were WebDAV resources
since they couldn't count on enumerating the namespace from a known WebDAV
compliant root. While there is still such a requirement since WebDAV allows
fully mixed namespaces (that is, a WebDAV compliant resource can have a
non-WebDAV compliant child who can have a WebDAV compliant child) it was the
consensus of the working group that the consistency requirements as they
stood were sufficient to meet the majority need and thus additional
namespace enumeration features to map inconsistent namespace could be left
for later. 

Finally, as Judy recently reminded us, we would have had to add features
such as "declare your parent" for collections which had performance
ramifications that were unacceptable to the overwhelming majority of the
working group. These concerns are similar to the ones that lead to PROPFIND
instead of making properties into resources and requiring two round trip
value resolution.

				Yaron

-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Thursday, November 12, 1998 5:29 PM
To: Yaron Goland; WEBDAV WG
Subject: RE: Clarification of URI vs. resource 



> There is no requirement that DAV enabled resources be in a DAV collection.
> Section 5.1 of 09 specifically states that DAV does not require the
> namespace to be consistent. Thus you can have DAV resources which do not
> necessarily have a DAV parent. The only rule is that if you do have a DAV
> resource and if it does have a parent (a term defined in spec) and that
> parent is DAV compliant then that parent MUST be a collection.
>

Right.  But this is exactly the behavior that Roy was concerned with.  Do
you think WebDAV needs to require this constraint?

- Jim

>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu]
> Sent: Thursday, November 12, 1998 2:54 PM
> To: ejw@ics.uci.edu
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Clarification of URI vs. resource
>
>
> >Roy Fielding agreed:
> >> I'll agree with Larry here -- I've been staying out of the debate
> >> largely because I don't understand the need for the requirement at all.
> >
> >The only problem is that I don't understand what constraint
> they're talking
> >about! Is this a discussion of case sensitivity, or namespace
> consistency?
>
> My comment was regarding the requirement that DAV capable resources be
> within a DAV collection.  There is no need for that requirement and it
> is the root of many terminology issues.  Any individual resource is
> capable of being or not being DAVable, as determined by either the
> capabilities described by an OPTIONS response or by the error response
> received when attempting to do a WebDAV operation on a non-DAV resource.
> "Save as..." dialogs are cool, but not necessary, for authoring.
>
> Eliminating the unnecessary requirement also removes any need to talk
> about how many different URI reference the same resource, or what
> might be the canonical preferred URI for a given resource.  It just
> doesn't matter if the definition is based on the request semantics
> instead of a paricular idealized model of the URI namespace.
> Instead, just define what a collection contains (its own namespace)
> and how to get a representation of that collection.
>
> This was also the meat of the primary (aside from locking) objection
> raised in Mark Anderson's critique of section 5 within
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0099.html>.
> In fact, I'd recommend replacing much of the existing section 5 with
> the text he articulated, or at least merge it in so that it is clear
> what motivates the discussion and explain why the "source resource"
> reference is actually the most significant bit that DAV adds to HTTP.
> Because it is, and I'm getting a tired of explaining what a server is
> supposed to do when a client tries to PUT to a derived resource.
>
> ....Roy
>

Received on Saturday, 14 November 1998 21:02:33 UTC