Re: Adding to configs

jamsden@us.ibm.com
Wed, 22 Dec 1999 07:37:43 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525684F.00463AFE.00@d54mta03.raleigh.ibm.com>
Date: Wed, 22 Dec 1999 07:37:43 -0500
Subject: Re: Adding to configs



I agree that with the semantics that Geoff describes for adding/removing
members from a configuration, but not the reuse of the LABEL method to do
so. It might be better to use a CONFIGPATCH method with an XML request body
like PROPPATCH that has add/remove elements. But I like treating a
configuration as a kind of collection and use BIND/DELETE. To solve Tim's
problem, we probably need to introduce a Destination-Target-Selector
header.






"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/21/99
11:59:35 PM

Sent by:  ietf-dav-versioning-request@w3.org


To:   ietf-dav-versioning@w3.org
cc:

Subject:  Re: Adding to configs



We should make sure that the add/remove revision from
configuration parallels the operation for adding/removing
a label from a revision, since these two operations are
semantically very close.

In particular, if a label is already on a revision of a versioned
resource, adding the label to a different revision will remove it from
the previous revision.  Similarly, if a revision of a versioned
resource is already in a configuration, adding a different revision to
the configuration will remove the previous revision from the
configuration.

For that matter, you could just model adding a revision to a
configuration as "labeling" that revision with that configuration, and
then just use the LABEL method.  Then if the body of the LABEL method
specifies a segment, it applies the label, while if it specifies
a URL, that URL must be a configuration and it "labels" that revision
with that configuration (adds it to that configuration).

We could just use two different method names (in which case, we need
a method name for the configuration add/remove), but the body and
semantics of these methods should be the same.

Cheers,
Geoff

   From: jamsden@us.ibm.com

   We talked about having a new method for this at DC. Want to consider
that
   solution?

   Tim_Ellison@oti.com (Tim Ellison OTT)@w3.org on 12/21/99 03:46:43 PM

   When adding a (versioned resource -> revision) to a configuration is the
   corrrect protocol:

   BIND <versioned resource URI>
   Target-Selector: <something to pick a revision of the versioned
resource>
   Destination: <config URI>/<versioned resource ID>

   That doesn't seem right since I can't say where the config working
resource
   is.

   How about:

   BIND <config URI>/<versioned resource ID>
   Target-Selector: <a workspace to pick a working config>
   Destination: <stable revision URI>

   Now that seems the wrong way around? and it means I _have_ to use a
stable
   revision URI.

   What do you think it should be?

   Tim
   p.s. it sure would be good to get rid of the <versioned resource ID>,
but
   that would create a problem for removing it with DELETE.