Next message: Tim_Ellison@uk.ibm.com: "Re: Naive question"
Date: Thu, 14 Sep 2000 00:49:26 -0400 (EDT)
Message-Id: <200009140449.AAA07653@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>
<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.
<jra> Perhaps we're not understanding each other or I'm missing
something. GET on a version selector does not return the contents
of the version selector, it returns the contents of the target
version.
The content of the version selector is required to be identical
to that of the target revision. An implementation can achieve this
by saving a copy of the content of the version in the target
selector resource, or by retrieving the content of the version.
So a version selector does have content, but that content happens
to be identical to that of its target version.
That target version can be specified either implicitly by
the DAV:target property of the version selector, or explicitly by
overriding this property using the Target-Selector header.
Not according to the protocol. The target of a version is defined
by its DAV:target property. That can only be changed by updating
its DAV:target property. The Target-Selector header can be used to
make a request refer to a version instead of a version selector,
but that doesn't change the target of that version selector.
The reasons for making this distinction have been described in
earlier messages in this thread (i.e. so that MOVE/LOCK/DELETE
and certain key live properties work properly).
This is
required for clients to be able to use labels to access old
versions of a resource through the version selector.
As mentioned earlier, the Target-Selector header is not required
to use labels to access old versions through the version selector,
but it does avoid one round trip (i.e. the round trip to retrieve
the version URL for that labeled revision).
So the target
selector is being used as a redirector for GET. The same thing is
true for PROPFIND, but only for dead properties.
I'm not sure what you mean by the "target selector". If you mean
the version selector, then it would be misleading to characterize
a version selector as a redirector for GET or PROPFIND, since that
would lead you to believe that a version selector is a redirector,
which is not the case for DELETE, MOVE, LOCK, etc.
PROPFIND doesn't
return live properties of the version when accessed through the
version selector.
That's correct, you'd have to ask for the live properties of
the version if they wanted the live properties of the version.
So clients would have to know the property they
are interested in is live on some server (the server may define its
own live properties on any resource) and that these properties have
to be accessed using different marshaling protocol - i.e., by using
the version URL instead of a version selector URL.
If you want the properties of the version, you'd use a version URL
(or use a Target-Selector header). If you want the properties of
a version, you'd use a version selector URL. No need to know whether
or not a property is live or not ... just use the appropriate URL.
So the things I'm trying to unify are 1) same semantics for accessing the
target version through a version selector's target regardless if it was
implicit through the DAV:target property, explicit through the
Target-Selector header, or explicitly using the version URL,
I'm afraid I still see no motivation or benefit for this unification,
and I do see MOVE/DELETE/LOCK behavior being broken, or at least,
made significantly more complex to define.
and 2)
consistent redirect semantics for version selector resources.
As with (1), I see no benefit for redirect semantics when it breaks
the MOVE/DELETE/LOCK behavior that we need.
As with the
original design of direct references, I think we need a way for the client
to say the method is operating on the version selector, not its target.
We decided not to pursue the original design of direct references,
(and did "bindings" instead), largely because of all of the problems
that arose when we tried to provide a sensible way for a client
to control when a method is being applied to the reference itself and when
it should be applied to the destination of the reference.
In particular, this approach basically breaks in the presence of
collections, depth operations, and MOVE/DELETE/LOCK semantics.
While it is true that in most cases, the expected default action would be
to operate on the target (e.g., DELETE) or on the version (GET), its
enumerating all the cases where the method does one or the other that
introduces complexity, and then there's always the case where the client
doesn't want to do the default. Unfortunately, as with the former direct
references, the expected default isn't always the same.
Which is exactly why we rejected the "direct reference" approach for
advanced collections.
Cheers,
Geoff