RE: DELETE in WebDAV Collections

>       RESOURCE - an basic entity in the server's underlying object store.
>       Usually similar to a file name in the most basic servers.
>
> I'd leave it more vague than that.  Some computed resources will
> not really be entities in the underlying object store, and it's not a
> filename since a filename doesn't have state, while a resource does
> (more like a file).
>
>    A given resource can be bound to more than one URI segment.
>
> I'd say "A given resource can be bound to multiple URI segments
> in different advanced collections, or multiple distinct URI segements in
> the same advanced collection."

While I more or less agree with Geoff's statement here, I did want to note
that there is a really good definition of resource in RFC 2396:

     Resource
         A resource can be anything that has identity.  Familiar
         examples include an electronic document, an image, a service
         (e.g., "today's weather report for Los Angeles"), and a
         collection of other resources.  Not all resources are network
         "retrievable"; e.g., human beings, corporations, and bound
         books in a library can also be considered resources.

         The resource is the conceptual mapping to an entity or set of
         entities, not necessarily the entity which corresponds to that
         mapping at any particular instance in time.  Thus, a resource
         can remain constant even when its content---the entities to
         which it currently corresponds---changes over time, provided
         that the conceptual mapping is not changed in the process.

So, it's not really appropriate to normatively define a resource as
something that only lives in an object store.  Plus, the definition is very
careful to note that a resource is a "conceptual mapping to an entity" but
is not necessarily the actual entity itself.  In the file system case, this
means a resource is a conceptual mapping to a file, not the file itself.

The definition is also explicit in noting that the resource can remain the
same, even though the entity it is mapped to can change over time.  So, a
resource can remain the same, even though it may be mapped to several
different files over its lifetime.

>       MAPPING - Usually a (full) URI to resource mapping.  As
> opposed to a URI
>    SEGMENT binding.  A resource can be mapped to many URI's, but it might
>    still only have one (binding to a URI segment of a) parent collection
>    resource.  This might be the case if an ancestor collection
> happens to be
>    bound to several URI segments.  -- There are other types of mappings.
>    Like, implicit ones created by heuristics on servers.  ie
> variant serving
>    URI's.
>
> Yes, I agree with all this.  In particular, this makes it clear that
> deleting all bindings to a resource has no defined effect on all
> mappings to that resource.

Huh?  At least in the example in the definition, deleting all bindings does
remove all mappings.

> You can create a new resource in an
> advanced collection with a PUT, MKCOL, or COPY.  This might create all
> sorts of mappings from URL's to resources, but none of them are
> bindings except for the original one requested.  The *only* way to
> create a second "binding" to the same resource is with an explicit
> "BIND" command.  Then a "DESTROY" or "DELETE -all-bindings"
> deletes the initial binding, and all *explicit* bindings created by
> the BIND command.

At first I wasn't too keen on differentiating between mappings and bindings,
but now I see that this distinction is really helpful, and I like it.

- Jim

Received on Saturday, 1 May 1999 19:49:27 UTC