Re: DELETE in WebDAV Collections

I agree that the key terms to be defined are binding, resource, state,
and mapping.  I believe I am in basic agreement with how Jason would like
to define these terms.  I'll highlight points of divergence below.

On the topic of states and versioning, an "immutable state" of a versioned
resource is represented by a distinct resource, called a "revision".  So
for versioning, there is no need to talk about "state" in any special way 
beyond how Jason describes it.

   From: ccjason@us.ibm.com

   4) There is a more natural way to do all this.   The terms are...
      BINDING - an association of a URI segment (of a collection) to a
   resource

I'd rephrase this to say:

"A binding is part of the state of an advanced collection, that
associates a URI segment with a resource.  In a given advanced collection,
a particular URI segment can be bound to at most one resource."

This makes it clear that bindings live in advanced collections, that
since a binding is part of the state of an advanced collection,
locking an advanced collection locks the bindings of that collection,
and that the bindings of an advanced collection revision are immutable.

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

      STATE - the actual state of a resource at a given "time".   The one's
   and zero's. A resource will evolve over time going through various states
   as developers refine it.  If the server is versioned, the states will be
   persistant and immutable.

I'd leave out that last sentence.  A checked-out versioned resource can go
through a variety of states, none of which are persistent or immutable.

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

Cheers,
Geoff

Received on Friday, 30 April 1999 23:44:11 UTC