Next message: Jim Doubek: "RE: Versioning TeleConf ... 2pm-3pm EST"
Date: Tue, 12 Sep 2000 17:42:16 -0400 (EDT)
Message-Id: <200009122142.RAA05703@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Naive question
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
I think there are some problems with what you describe below. Any
operation on a version selector should be redirected to the target
version including PROPFIND/PROPPATCH regardless if a Target-Selector
header was specified or not.
Why?
Some of the reasons that operations on a version selector are not
just redirected to the current target version include:
- a MOVE of a version selector is different from a MOVE of the
target version
- a DELETE of a version selector is different from a DELETE of the
target version
- a LOCK of a version selector is different from a LOCK of the
target version (the lock properties appear on the version selector,
not on the version)
- the members of a collection version selector are version selectors
and versionable resources, while the members of a collection version
are version histories (this is discussed at length in several earlier
threads in this mailing list).
- for efficiency (and other reasons), many servers will want to have
certain live properties of a version selector to be distinct from
those of the target version, so that the target version does not have
to be queried/updated whenever the version selector is (and vica
versa).
The Target-Selector header is only there to
override the DAV:target of the version selector. We don't want different
semantics depending on how you specified you version.
I disagree. The semantics of a version selector are very different from
those of a version (see above). The Target-Selector header is there to
give you a convenient way to access a version resource, *NOT* as a
replacement or alternative for a version selector.
Version selectors
are special resources, not bindings (too bad, but they aren't), so we
can define the semantics of PROPFIND/PROPPATCH on a version selector to
return both its properties and the properties of its target version.
Or we can define that the dead properties of a version selector are
identical to those of the current DAV:target version. Achieves the
desired result, without breaking the necessary distinction between
a version selector and a version.
There should be no overlap, so no properties will be hidden.
I think this is consistent with the definition of target in the core
versioning section.
Consistency with the definition of target is not the issue -- correct
version selector and version semantics is.
Cheers,
Geoff
From: Tim_Ellison@uk.ibm.com
How do you refer to a version selector rather than the version it
selects?
(i.e. to PROPFIND/PROPPATCH it's properties)
A version selector has a URL which is different from the URL
of any particular version. When you do a PROPFIND/PROPPATCH on a
version selector URL, you operate on the properties of the version
selector. When you do a PROPFIND/PROPPATCH on a version URL,
you operate on the properties of the version.
Note though that all the dead properties of a version selector
correspond (i.e. have the same value) as those of the version that
is that target of that version selector.
Further note that if you use a Target-Selector header with a
PROPFIND/PROPPATCH request, you operate on the properties of
the selected version, and *not* on the properties of the
version selector.
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
You can't. PROPFIND returns the properties of both.
PROPFIND returns the properties of whatever resource you
applied it to. In particular, the live properties of a version
selector can be different from those of its target version.
A while back, we modeled version selectors as a "redirector"
that redirected methods to the version, but that was a
good while ago, before we looked carefully at modeling
versioned collections.
Note that we can
create version selectors with VERSION-CONTROL, but DELETE doesn't
actually say you can delete them.
You can use DELETE to delete a version selector.
DELETE of a version is undefined.
That is correct, but DELETE of a version selector is defined.
DELETE on a version selector should just delete the version selector,
but then we have a special case where the version selector is
accessed
as a resource itself.
A version selector is always accessed as a resource itself.
A Target-Selector header can be used to redirect a request
from a version selector to the specified version, but without
a Target-Selector header, a method applied to a version selector
URL is applied to the version selector resource.
Remember the BIND/DELETE/UNBIND arguments? Geoff?
Yes, we used to need this kind of argument when we modeled
version selectors as redirectors, but we don't need them
any more, now that we don't model them that way anymore.
Cheers,
Geoff
--=_alternative 0072E64385256958_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">Geoff,</font>
<br><font size=2 face="sans-serif">I think there are some problems with what you describe below. Any operation on a version selector should be redirected to the target version including PROPFIND/PROPPATCH regardless if a Target-Selector header was specified or not. The Target-Selector header is only there to override the DAV:target of the version selector. We don't want different semantics depending on how you specified you version. Version selectors are special resources, not bindings (too bad, but they aren't), so we can define the semantics of PROPFIND/PROPPATCH on a version selector to return both its properties and the properties of its target version. There should be no overlap, so no properties will be hidden.</font>
<br>
<br><font size=2 face="sans-serif">I think this is consistent with the definition of target in the core versioning section.</font>
<br>
<br>
<br>
<br><font size=2><tt> From: Tim_Ellison@uk.ibm.com<br>
</tt></font>
<br><font size=2><tt> How do you refer to a version selector rather than the version it selects?<br>
(i.e. to PROPFIND/PROPPATCH it's properties)<br>
</tt></font>
<br>
<br><font size=2><tt>A version selector has a URL which is different from the URL<br>
of any particular version. When you do a PROPFIND/PROPPATCH on a<br>
version selector URL, you operate on the properties of the version<br>
selector. When you do a PROPFIND/PROPPATCH on a version URL,<br>
you operate on the properties of the version.<br>
</tt></font>
<br><font size=2><tt>Note though that all the dead properties of a version selector<br>
correspond (i.e. have the same value) as those of the version that<br>
is that target of that version selector.<br>
</tt></font>
<br><font size=2><tt>Further note that if you use a Target-Selector header with a<br>
PROPFIND/PROPPATCH request, you operate on the properties of<br>
the selected version, and *not* on the properties of the<br>
version selector.<br>
</tt></font>
<br>
<br><font size=2><tt> From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com><br>
</tt></font>
<br><font size=2><tt> You can't. PROPFIND returns the properties of both.<br>
</tt></font>
<br><font size=2><tt>PROPFIND returns the properties of whatever resource you<br>
applied it to. In particular, the live properties of a version<br>
selector can be different from those of its target version.<br>
A while back, we modeled version selectors as a "redirector"<br>
that redirected methods to the version, but that was a<br>
good while ago, before we looked carefully at modeling<br>
versioned collections.<br>
</tt></font>
<br><font size=2><tt> Note that we can<br>
create version selectors with VERSION-CONTROL, but DELETE doesn't<br>
actually say you can delete them.<br>
</tt></font>
<br><font size=2><tt>You can use DELETE to delete a version selector.<br>
</tt></font>
<br><font size=2><tt> DELETE of a version is undefined.<br>
</tt></font>
<br><font size=2><tt>That is correct, but DELETE of a version selector is defined.<br>
</tt></font>
<br><font size=2><tt> DELETE on a version selector should just delete the version selector,<br>
but then we have a special case where the version selector is accessed<br>
as a resource itself.<br>
</tt></font>
<br><font size=2><tt>A version selector is always accessed as a resource itself.<br>
A Target-Selector header can be used to redirect a request<br>
from a version selector to the specified version, but without<br>
a Target-Selector header, a method applied to a version selector<br>
URL is applied to the version selector resource.<br>
</tt></font>
<br><font size=2><tt> Remember the BIND/DELETE/UNBIND arguments? Geoff?<br>
</tt></font>
<br><font size=2><tt>Yes, we used to need this kind of argument when we modeled<br>
version selectors as redirectors, but we don't need them<br>
any more, now that we don't model them that way anymore.<br>
</tt></font>
<br><font size=2><tt>Cheers,<br>
Geoff<br>
</tt></font>
<br>
<br>
<br>
<br>
--=_alternative 0072E64385256958_=--