Re: bind draft issues

> The URL is an identifier for the resource, which allows the client to
> interact with the resource (in HTTP mainly by retrieving and 
> manipulating
> representations of these resources). WebDAV has added collections and
> properties, but these do not really change the underlying model.
>
> When I submit a request to an HTTP server, it uses the request URL to 
> locate
> an internal resource object. HTTP allows multiple URLs for the same
> resource. Once the object was located, the name (the request URL) 
> becomes
> irrelevant -- the results of the interaction should be independant of 
> the
> way the server located the resource.

It uses the request URI to locate an implementation object.  Neither is
the HTTP resource.  The name is always relevant in this process, even 
after
the implementation object is found, because the implementation will use
the name to determine which representation should be returned in 
response
to a GET.  Each representation has its own set of properties.  It is
therefore false to say that two bindings to the same WebDAV resource 
will
have the same properties because WebDAV defines the resource to be the
implementation object (unlike HTTP).

WebDAV doesn't understand server-side content negotiation because it
doesn't deal with negotiated URIs.  The bindings spec has no choice
but to understand it, since that is the primary reason to have bindings
(as opposed to redirects).  In order to make sense of bindings it is
necessary to return to the proper definition of resource and
representations, wherein it never makes sense to say that the binding
attaches to a resource, because the binding is part of what defines
the HTTP resource (the mapping function).

> Using my favorite analogy (the Unix filesystem :-)

The Web is not a distributed filesystem.  Resources are not files.
Why use broken analogies to explain a process which is self-evident
in almost all general-purpose HTTP origin servers?  Just use what
has already been implemented.

....Roy

Received on Friday, 7 March 2003 19:25:21 UTC