Next message: Geoffrey M. Clemm: "cleaning up the REPORT elements"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256855.00692796.00@d54mta03.raleigh.ibm.com>
Date: Tue, 28 Dec 1999 14:05:55 -0500
Subject: Re: Target-Selector
Ok, I see now. So it doesn't look like we need an override-header because
BIND isn't operating on a specific revision but the versioned resource as a
whole.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/28/99
01:28:17 PM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: Re: Target-Selector
From: jamsden@us.ibm.com
But it seems like there is a big difference between COPY and BIND in
that
copy does overwrite the contents of the destination meaning that any
other
URL bound to the same destination resource will see the new contents.
No, a COPY as currently defined by 2518 does not overwrite the
contents of the resource at the destination, it deletes (unbinds) the
resource at the destination, and then binds the Destination URL to the
newly created copy. So any other URL bound to the resource at the
Destination before the COPY will see the same contents before and
after the COPY.
BIND
on the other hand does not change the contents or properties of the
destination, it just gives it a new name.
Depends what you mean by "destination". If you mean "the resource at
the Destination URL prior to the BIND", then BIND doesn't give it a new
name, it just gets rid of one of its existing names. If you mean
"the resource at the Destination URL after the BIND", then yes, it gives
it a new name.
The same statement holds for the COPY operation.
Other URLs bound to the same
resource are uneffected. So it doesn't seem like it should be necessary
to
checkout a revision to bind a new URL to it. The collections containing
the
existing destination member, and the new destination member would have
to
be checked out if they are versioned, but not the resource being bound
to.
Right?
Yes.
If so, then the BIND destination will need both workspace and
override-selector headers.
You definitely need a workspace header (to specify which workspace the
checked out collections are in), but you don't need an override-selector
header, since it is the versioned resource as a whole that is being
moved, not a particular revision of it. And I don't believe that the
relatively infrequent operation of "moving" a resource from a checked out
collection in one workspace to a checked out collection in a different
workspace warrants the addition of a special "Destination-Workspace"
header.
In those infrequent cases where you really want to do this, you can
do so with a BIND/DELETE sequence.
Cheers,
Geoff
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/28/99
From: jamsden@us.ibm.com
How does BIND modify the destination? This seems like the one case
where
the destination workspace and override-selector headers would be
needed
the
most.
A BIND is just like a MOVE, except you don't delete the request-URL.
So the request-URL remains unchanged (i.e. is still bound to the same
resource), but the Destination URL becomes bound to the same resource as
the request-URL. Just like COPY, you can use an Overwrite header to
indicate how BIND should deal with the case where the Destination URL
currently identifies a resource.