Re: Clarification of URI vs. resource

Sorry Yaron, but you can't rationalize a protocol requirement by
referring to working group opinions.  Either it has a reason to
exist or it is not a protocol requirement, and therefore not needed
in the specification.

>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. 

That is a false design principal.  It is the server's responsibility to
maintain a consistent namespace, not the protocol's responsibility.
Making implementation decisions in the protocol violates an HTTP design
principle that far outweighs WebDAV.

>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.

That is unnecessary FUD.  There is no scenario in which the capabilities of
the surrounding namespace are required to be of a certain nature in order
to know whether a WebDAV operation succeeded or failed.  There is absolutely
nothing in WebDAV to prevent the protocol from successfully authoring a
resource that exists only as a singleton DAV-capable name on any server
in any preexisting namespace.  HTTP is stateless.  If ensuring such a thing
would require "extra gunk", then the protocol won't work in any namespace.

>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.

You can't do that with the existing protocol anyway, nor is it a necessary
requirement for distributed authoring.  It is silly to restrict the range
of potential implementations just because somebody wants a feature.

>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.

I don't need any such features.  I know what resources are authorable
in my own namespace.  I even know what collections they are in.  Having
the client determine the latter might be desirable, but I don't need it
in order to do distributed authoring.

There is no interoperability requirement for WebDAV namespaces other
than the notational prefix implications of operations on collections,
and that requirement only exists when WebDAV collections are being
acted upon in a recursive fashion (and even then its only purpose is to
denote what member resources are included in the recursion).  It is thus
unnecessary to make claims on namespace consistency or DAV compliance
for anything other than the specific resource(s) being operated upon during
a WebDAV request, and all such cases should be prepared to handle an
HTTP response of 501 or 405.

....Roy

Received on Tuesday, 17 November 1998 00:32:27 UTC