Next message: Clemm, Geoff: "RE: 4xx response body values"
Message-ID: <3906C56A7BD1F54593344C05BD1374B179A11D@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: ietf-dav-versioning@w3.org
Date: Wed, 13 Sep 2000 19:49:04 -0400
Subject: RE: Naive question
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
Ok, so perhaps it wasn't such a naive question ...<g>
I've read the spec, and I've read the posts to this list, and I'm
confused
about how to think about version selectors. They certainly seem to
have
some strange characteristics. They are a real resource, but without
their
own resource type (adopting the type of the resource they target,
hmm, ok.
This is just because (it is believed) current DAV implementations would
get confused if they encountered structured DAV:resourcetype values.
Otherwise we could just add DAV:version-selector to the DAV:resourcetype
value (in addition to whatever value the versionable resource had).
Note that this is true for working resources as well, so it may be strange,
but it is not a strangeness unique to version selectors.
Version selectors seem to be pitched as a reference,
Not by me (:-). According to the protocol, they "provide access" to a
version, but they are never described as "being a reference". This is
further clarified in the section 2.2:
"Another way to modify the state of a version selector is to use
a SET-TARGET request to select another version to be the target
of that version selector. The SET-TARGET request will set the
content and dead properties of the version selector to be
those of the specified version."
We could certainly add some words here (and/or elswhere)
if it would help make this clearer.
but if I think of a
version selector as a redirector (c.f. redirect reference) the
mental model
fails since the live properties of the target cannot be seen via the
version selector. Instead you see the live properties of the
version
selector itself together with the dead properties of its target.
This
merged view seems counterintuative to me. In this model I would
expect
something like the old Target-Selector: metadata (or
'version-selector' as
jra suggested) to refer to the version selector itself, and all
other
requests to be redirected.
Yes, that's why you should not think of the version selector as being
a reference.
If I think of the version selector as a copy of the version (content
and
dead properties) it selects then maybe it makes a bit more sense.
The live
properties were not copied so you don't see them in the version
selector,
and there is no call for a 'metadata' type header.
Yes, that's a better model. But note that you do not have to *implement* it
as
a copy, i.e. you can just redirect back to the version to get the content or
dead properties from there.
But now there is no
resource that is a version selector (it is just a copy)
Why is a copy not a resource? In fact, that's the difference between COPY
and MOVE ... COPY creates a new resource, while MOVE just renames an
existing
resource.
and the 'selector
is a reference' pitch is broken.
Yes, the "selector is a reference" pitch is broken (which is why the
protocol
shouldn't makes this pitch :-).
If someone could attempt a description of a version selector I'd
appreciate
it.
Your "copy-based" description is just fine. A version-selector displays a
copy of the content and dead properties of a particular version (namely, the
one identified by its DAV:target property).
An additional live property (beyond DAV:target and DAV:lockdiscovery) that
will commonly have different values on a version selector and its target
version
is DAV:getlastmodified.
It is common for a server to increase DAV:getlastmodified on a target
selector
whenever the DAV:target is changed, while the DAV:getlastmodified value
of the target will decrease when an earlier version is made the target.
Cheers,
Geoff