Next message: Tim_Ellison@uk.ibm.com: "Re: Naive question"
Date: Tue, 12 Sep 2000 23:12:05 -0400 (EDT)
Message-Id: <200009130312.XAA06056@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" <marjorie@us.ibm.com>
See <jra> tags. But the primary point is that clients will expect the
version selector to redirect to the target for contents whether the target
is the default (specified by the DAV:target property of the version
selector), or explicitly specified in the Target-Selector header.
Yes, the protocol states that the content and dead properties of a
version selector are those of its current target.
It is
reasonable that PROPFIND should behave the same way, and except for live
properties, the spec says it does. I'm only suggesting that we remove this
special case.
PROPFIND cannot act the same way for the DAV:target property, and
cannot act the same way for the lock properties (please refer to
recent threads for the rationale for this). No DAV protocol has
placed generic restrictions on the behavior of live properties,
and I do not propose that we do so in the versioning protocol.
The list of cases you describe below indicate that we are getting close to
creating too many special cases in the protocol.
We only create too many special cases if we try to "unify" version
selectors and revisions. They are different kinds of resources,
and therefore it is expected that they should act differently.
Version selectors have semantics like bind/redirect references, but
are not bindings or redirect reference resources. So they end up
introducing a lot of special cases that make the protocol more
complicated.
Why would any relationship (or lack thereof) between bindings
(or redirect references) and version selectors introduce "a lot
of special cases"? I suppose you can call the varous reasons
why a version selector is different from a version a set of
"special cases", but that doesn't make them go away (:-).
<geoffrey.clemm@rational.com>
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
<jra>
This is not described in the spec. MOVE and DELETE introduced the most
difficult issues in the binding protocol. I hope we're not re-introducing
all those problems with version selectors.
According to the curent protocol, a DELETE of a version selector is
just a standard DELETE, while a DELETE of a version is undefined (for
reasons we've recently discussed in this mailing list). I don't see
that these are difficult issues or problems ... just different
behaviors for different kinds of resources.
- 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)
<jra>
Then LOCK is ambiguous.
How so? A version selector is a different resource from the version
that is its current target, so a lock that is applied to a version
selector locks that version selector, while a lock that is applied
to a version locks that version. Seems pretty straightforward
to me (:-).
I don't like the protocol using very different
semantics on the same target URL based on control couples in headers.
A version selector has one URL and the current target of that version
selector has a different URL (i.e. the URL stored in the DAV:target
property). So there are two URL's, with the standard lock semantics
on each. I'm not sure what you are referring to as a "control couple
in headers".
Headers should parameterize the operation, not change its meaning entirely.
Perhaps you are talking about the Target-Selector header here?
A Target-Selector just lets you redirect a method from a version
selector to a selected revision. It doesn't "change the meaning entirely"
of the request, it just applies the request to a different resource.
Now the fact that a different resource responds differently to a
given method is to be expected.
As with the direct and redirect references arguments, if a resource needs
to be a resource sometimes, and a binding to another resource some other
times, we need to expose clear protocol for distinguishing them.
A "binding" is not a resource, it is just a way of modeling the
state of a collection. A redirect reference is just a resource
(distinct from the resource it refers to). Just as with version
selectors and versions, a redirect reference is one resource and
its reference is another resource (each with its own URL).
The way you distinguish them is by the fact that they have
different URL's (again, just as is the case for version selectors
and versions).
This is
not the case for version selectors because sometimes the absence of a
Target-Selector causes the method to operate on the version selector, and
sometimes it doesn't.
The absence of a Target-Selector always means that the method is
applied to the version selector (i.e. the normal behavior). A
Target-Selector is just a hack (and one that I'd be happy to get rid
of) that lets you get from one resource (the version selector) to
another (a version) in a single request. You can do the same thing
without a Target-Selector header, by applying a property report to the
version selector (to find the version URL you want), and then apply
the method to the version URL. A useful hack, but a non-essential one.
Maybe we need a header to say the method operates on
the version selector, not the target as in
Target-Selector:version-selector. Then MOVE or DELETE will (usually) fail
if the target is a version not the version selector. Then no special
cases. This is ugly too, but at least it could be consistent.
Except that the normal (and sufficient case) is that all the
methods *should* apply to the version selector. It's not just
MOVE and DELETE ... it's LOCK and any new methods that get
introduced (such as BIND, which again, needs to be applied to
the version selector and not to the version).
All of these problems are introduced by trying to force a version
selector to always redirect a method to a version. There is an
easy answer: just don't do that.
- 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).
<jra>
This depends entirely on the properties the client asks for, not the
semantics of the protocol itself.
</jra>
My point (and it is a relatively minor one) is that some servers want
to have some live properties that exist on the version selector that
are "local" to the version selector, i.e. that do not appear on the
version. The inability to do this is just one of the problems with
modeling the version selector as a redirector to a version.
In any case, the lock properties and the DAV:target property of a
target selector are ones that are "local" to the target selector.
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.
<jra>
The difference is not between a version selector and a version, but the
target of a version selector specified by its DAV:target property or
through the Target-Selector header. These both specify a version.
</jra>
If they act differently, they are different resources. I suppose you
could try to develop a model in which the name of a resource determines
its semantic properties, but I see no reason to do so.
<jra>
No problem with the dead properties, its the live properties that are at
issue. We should avoid defining the protocol so that clients have to use
different marshaling for some properties than others.
</jra>
I have seen no proposal that a client use different marshaling for
some properties than others.
Cheers,
Geoff