Re: draft-ietf-webdav-binding-protocol-02

[Yeah, I know, a little late ...]

In message <10001211656.AA26520@tantalum>, "Geoffrey M. Clemm" writes:
>This is a model we considered (and JimW even did some impressive ASCII
>art to illustrate it), but we found that saying that "every URI
>identifies a unique resource" makes the term "resource" irrelevant.

If the purpose of the spec was to define "resource", then I would agree
with you.  However, it isn't -- resources cover a lot more ground than
even HTTP/1.1 as a whole defines.  What I said was that "for the purposes
of the bind protocol" you can consider each URI to identify a unique
resource, because the purpose of bind is to create new identifiers
without the addition if another implementation mechanism (hence, whether
or not it creates a new resource in the process is not applicable).

>The point of the binding spec was to allow two different URI's to
>identify the same "something".  If we say that every URI identifies a
>unique resource, then we need another term, say "object", and now all
>of our semantics are in terms of URI's and objects, i.e. "A bind
>causes two URI's to be mapped to the same object".

The spec's problem is that it is trying to define BIND in terms of the
server implementation instead of in terms of its impact on the Web interface.
There is no terminology in HTTP for the implementation thingies because
we didn't want anything in the protocol to influence the set of possible
implementations using the protocol.

It is the nature of every engineer to define things in terms of the
characteristics of the components that will be used to compose the
finished product.  The Web doesn't work that way.  The Web architecture
consists of constraints on the communication model between components,
based on the role of each component during an application action.

Bindings need to be defined in terms of how it impacts the interface.
A binding creates a new name in a collection's namespace which has
an implementation mechanism identical to that of the bound resource.
That's the semantics, in one sentence.  The rest of the spec should
simply define the syntax used to express those semantics.

....Roy

Received on Saturday, 12 February 2000 22:16:51 UTC