Re: A proposal for Advanced Collection binding semantics

   From: Jim Whitehead <ejw@ics.uci.edu>

   > The state of an advanced collection includes a set of "bindings".  A
   > binding is an association of a name (a string) with a resource.  A
   > legal binding name must satisfy the constraints for a URL path segment,
   > as defined by section 3.3 of RFC 2396.  (Note: if the definition of
   > "internal member name" is fixed in RFC 2518, we can just use that as
   > the binding name).

   We might want to strengthen the definition of "internal member" that is in
   RFC 2518.

   Your definition needs to be extended to allow for internal member names to
   end in a "/", and to be consistent with RFC 2518, they should start with
   "./".

Actually, by "fixing" RFC-2518, I meant to add the concept of an
"internal member name" (currently RFC-2518 only defines the concept of
an "internal member URI").  I'd like to retract and apologize for the
use of the word "fix" in this concept, since there is nothing "broken"
about RFC-2518 in this regard.  This change might help clarify the
concept of an internal member, so it might be useful to add to RFC-2518
for that reason.

Then an internal member name would be a URI segment, and an internal
member URI is created by concatenating a URI of the collection with
the internal member name, and then appending a "/" if the internal
member is a collection.

But it's just as easy to define "binding name" in the advanced collection
protocol, and then indicate how an internal member URI is produced from
the binding name.

   > - The BIND method
   >
   > The new BIND method is provided to allow direct manipulation of
   > bindings.  In particular, BIND can be used to create a new binding to
   > an existing resource,

   I agree with this.

   > or to modify an existing binding (by associating
   > it with a different resource).

   But I don't like this, since it's essentially an atomic UNBIND/BIND pair.
   My concern is whether such an operation is really needed, and whether this
   means that access control for BIND can be disentangled from access control
   for UNBIND.  It seems like a bad separation of concerns.

Isn't that like saying that a PROPPATCH is an atomic "remove property/
add property" pair?  Remember that a BIND is a modification to the
advanced collection containing the binding.  A BIND to an existing
binding modifies the state of the advanced collection by changing the
resource associated with an existing binding.  A BIND to a non-existent
binding modifies the state of the advanced collection by adding a new
binding (with the specified binding-name to the specified resource).
Forcing a state modification of a single resource (the advanced collection)
to be divided into two requests does not make sense to me (and I'll appeal
again to the PROPPATCH analogy).

   > But the inverse does not hold, namely, the fact that the server maps
   > two URL's to the same resource doesn *not* imply that this resource
   > must be an internal member of an advanced collection, *nor* does it
   > imply that there must be two bindings to that resource.  For example,
   > if the server maps http://host/todays-weather.html to the same
   > resource as http://host/5-1-1999-weather.html, this does not imply
   > that http://host is an advanced collection, nor that there are two
   > bindings to this resource.

   I'd add:

   However, if http://host/ is an advanced collection, then it MUST have
   bindings to todays-weather.html and 5-1-1999-weather.html.
   That is, the existence of multiple mappings doesn't imply the collection is
   advanced, but if it is advanced, every mapping must have a corresponding
   binding.

I totally agree.

   > ...
   > Note: This definition of delete is compatible with RFC-2068, but is
   > not compatible with wording in RFC-2518.  I support Jim Whitehead's
   > proposal that the wording in RFC-2518 be modified in order to allow
   > this definition of delete.

   Right -- we'll make this change going from Proposed to Draft.

Excellent!

Cheers,
Geoff

Received on Sunday, 2 May 1999 10:32:13 UTC