Re: Versioning spec review - 02.3
jamsden@us.ibm.com
Tue, 26 Oct 1999 09:20:28 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256816.0049881A.00@d54mta03.raleigh.ibm.com>
Date: Tue, 26 Oct 1999 09:20:28 -0400
Subject: Re: Versioning spec review - 02.3
See <jra> tags below. This thread is getting long. Sorry for the continuing
detail.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 10/25/99 05:41:31 PM
To: w3c-dist-auth@w3.org
cc:
Subject: Re: Versioning spec review - 02.3
From: jamsden@us.ibm.com
Last paragraph: How about using components of versioning support instead
of
"levels"?
In the latest rev of the spec, the versioning options fell quite naturally
into 3 levels, so given the client-side advantages of having 3 levels of
support vs. multiple orthogonal versioning options, I'd like to go with
levels, if at all possible.
<jra>
We went to a lot of trouble trying to establish levels only to eliminate
the concept in Concord. It seems too bad to reintroduce them now. I hope we
don't go over that same ground again. I wasn't helpful getting the
versioning semantics down.
</jra>
B.T.W., this isn't mentioned in the
semantics of CHECKIN. Looks like mutable revisions are missing from
CHECKIN although the postconditions mentions the concept.
Do you mean something like "If DAV:overwrite=T then the server MUST
support DAV:overwrite having the value T"? (:-)
<jra>
No, I mean we need to say that the server can fail the operation or
overwrite the revision. I don't remember seeing this in the postconditions
of CHECKIN.
</jra>
<jra> What is the URL for the baseline? Is it something the server
generated, or is it derived from the associated collection.
All baselines for a particular versioned collection can be found in
the DAV:baselines collection of that versioned collection. The
server generates the URL of that collection, and generates the
name for a baseline in that collection.
<jra>
So baselines don't have human meaningful names or labels? How will a user
distinguish one fron another?
</jra>
The
protocol doesn't say how a baseline is created, or how this URL is
derived. Did I miss this? I don't see anything in CHECKIN.
I took that out, since I agree with your contention that it doesn't
properly
belong in CHECKIN. So you now just create baselines with the MKRESOURCE
command. There's a ToDo note in the draft saying this should be explicitly
mentioned in the MKRESOURCE method description.
<jra>
I don't recall MKRESOURCE mentioning creating baselines, or the semantics
of how one was created. Does the collection have to be checked in? Can it
have working resources in this or any other workspace? How is the baseline
identified or distinguished from another baseline?
</jra>
In any case, any place where a specific revision is required, but
revision id must be specified. For example, putting a configuration in
the RSR. The same must be true of baselines.
Baselines and revisions are indicated in RSR's by their URL's. We
could allow alternative compound notations as well, but is there
a compelling reason to do so (it does add complexity).
<jra>
So the human meaningful name (its human URL and revision id) for a revision
can't be used in the RSR? If we had a method for setting the RSR, the
server could translate human names into revision URLs and back.
</jra>
How is constraining a "property collection" any harder than
constraining a method? You write down the constraint, and servers and
clients must follow it.
<jra> A method can define specific semantics that are supported. It
doesn't have to list a bunch of things you can't specify.
</jra>
I had no trouble specifying the appropriate constraints on the
appropriate properties in the protocol. Live properties commonly have
their values constrained by the server, so this is nothing unusual for
WebDAV.
<jra>
Its not just the properties you're describing, its the use of the PROPPATCH
and BIND methods too. For example, adding a revision to a configuration
with BIND. BIND has a set of semantics of its own, but binding a revision
to a configuration has more semantics. Similarly, CHECKOUT with a
propertyupdate for setting the checkin policy should not be allowed to do a
general PROPPATCH. It should only set checkin policy so the CHECKOUT method
can determine if it should fail or succeed depending on whether the
proposed checkin policy can be met.
</jra>
having a downlevel lock check out the resource into the default
workspace has the right semantics for down level clients working
against auto-versioned resources ... the PUT that would auto- version
fails because the resource is already checked out into the default
workspace.
<jra> Nice idea, but I think it overloads lock too much. Another
way to look at it (from the point of view of a non-versioning aware
client) is the lock prevents anyone else from checking out the
revision. So the down-level client locks, does a bunch of PUTs knowing
that no-one else can change the resource, and then does an
unlock. Each PUT still does a CHECKOUT/PUT/CHECKIN, but only the
down-level client can directly or indirectly checkout the
revision. The effect is the same, but this keeps lock out of
checkout/checkin which might be a good thing.
</jra>
One of the bad things about creating a new revision on every downlevel
PUT is that it fills the history of a resource with "non-interesting"
revisions, but we have to do it to prevent lost updates. In contrast,
a LOCK/UNLOCK request gives us exactly the information we need to
implement a more intelligent revision creation policy. To not take
advantage of this information when designing the protocol strikes me
as remiss.
<jra>
Lock is an access control mechanism. We've already got the method and
need to have it mean something. This is just an attempt to do
something reasonable. If we want to keep locking optional though,
we'll have to make sure none of this functionality is required.
</jra>
Current WebDAV locking (with lock tokens) are good for some things,
but any time it is not reasonable to expect a client to hold and
remember a lock token, WebDAV locks are not appropriate. It is better
to just have the protocol treat the operation as undefined or an
error, rather than increase the complexity of the protocol (and of
servers that implement it) with functionality that is not useful.
<jra>
I don't think this increases the complexity. Disallowing the method for
special cases also increases complexity.
</jra>
Marshalling, how is the Target-Selector overridden with a
specific label or id?
It isn't. The Target-Selector with a label or id is just for folks with
lightweight workspaces that don't have rsr's. For folks with
workspaces,
overriding with a specific label is far less common, and can be done by
accessing the DAV:revisions or DAV:revision-labels collections.
<jra>
Two problems: if the Target-Selector is just a label, what is used to
select the collection revisions in the URL path?
Core and Activity versioning servers will not be generating versioned
collections, so there will be no collection revisions in the URL path.
Versioned-Collection servers will provide repositories, which are
required to be located in a non-versioned part of the namespace
(i.e. under no versioned collections). In either case, the
DAV:revision-labels
collection will have no collection revisions in its URL path, so no
collection revision selection is required.
<jra>
I'm missing something. If you have a bunch of versioned collections in a
hierarchy, and you want to access a specific revision of a member of one of
them, then you need two things: the workspace to use to select the righ
revisions of versioned collections along the path, and a revision name to
select the specific revision of the member versioned resource. We don't
want to require users to us repository and server implemented URLs for
this.
</jra>
Second, folks with
workspaces will override with a specific label LOTS of times to do
compares, browse old versions, prepare for merging, look at what other
people are doing, etc.
The DAV:revision-labels collection is there to give clients easy access
to any revision by using a label. No need for a specific header, and
suitable for use in any context where a URL can be specified (as opposed
to the Target-Selector, which just works for a Request-URL).
<jra>
It is not acceptible to require clients to translate URL and revision names
into server generated revision URLs for this operation. The client should
always be able to use the name they know a revision by to access that
revision.
</jra>
CHECKIN is doing PROPPATCH work. This is not a propertyupdate, its a
set of parameters for the CHECKIN method. We should not reuse the
propertyupdate, but rather create a new element, specific to the
method. Otherwise we have to specify a whole bunch of restrictions
about what can go in the propertyupdate.
Not if we place no restrictions on what can go in the property-update.
Note that I'm happy to say no specification of the DAV:checkin-policy
in a CHECKOUT request, but if we *do* allow it, I believe that the
most appropriate way is to allow CHECKOUT to do an arbitrary PROPPATCH
to "initialize" the new working resource. Think of CHECKOUT as a
"MKRESOURCE" for working resources.
<jra>
Can't agree with this. CHECKOUT creates a working resource that is a copy
of the checked out revision, there is no need to "initialize" it any
further. Second, the CHECKOUT should succeed or fail based on checkout
semantics, not property updates. This is way too much coupling and will
make the method difficult to describe and implement. Finally, I still think
it is entirely unnecessary for checkout to do anything with checkin
semantics. If a client wants to perform these policy checks or property
updates, let it do it after the checkout, and do an uncheckout if they
can't get the checkin they want. We need to simplify these methods, and
this would be a good place to start. We have no use case requiring this,
and I think it is unnecessary semantics optimization.
</jra>
I don't think we need two ways of updating properties on a resource,
PROPPATCH and CHECKIN. You say later on that some of the properties
are not actually saved. This is even worse. Method parameters should
be coupled with the method, not the resource.
We already have two: PROPATCH and MKRESOURCE. So if we add a third,
there is at least precedent.
<jra>
But we have an issue to get rid of MKRESOURCE for this very reason.
Besides, the point of MKRESOURCE is to support resource creation as a first
class operation rather than a side effect of PUT.
</jra>
Having "uncheckout" as an option to CHECKIN is reasonable because
they are logically very similar in basic intent (i.e. "I'm done
with this resource"). We already have DAV:overwrite which doesn't
create
a new revision, and DAV:identical-uncheckout which only creates a new
revision if it has changed, so DAV:uncheckout seems to fit in very
smoothly.
<jra> But I think the intent of the two methods is the exact
opposite. The intent of CHECKIN is to create a new revision an
preserve changes unless perhaps there's no need to because there were
no changes. The intent of UNCHECKOUT is to ensure a new revision is
not created, and the changes are lost. Coupling these two concepts in
the same method seems wrong. This is taking control couples too far.
Both DAV:overwrite and DAV:indentical-uncheckout conflict with your
description of the intent of CHECKIN. One never creates a new revision,
and the other only sometimes creates a new revision.
<jra>
But they don't conflict, they are an optimization of creating new revisions
by avoiding creating revisions that have no changes.
</jra>
Notice that most of these
checkin policies could be marshalled in simple headers.
So we could use up the single header namespace, instead of using XML
which has user-defined namespaces ? (:-)
<jra> Since we own headers, there is no namespace issue.
This "we" is a very diverse group (i.e. everyone proposing extensions
to HTTP) with overlapping needs/interests. Using up a name that is
"global" to this group is, in my opinion, a very significant issue.
After all, we've already made life difficult for the archery extension
group by defining the semantics of "Target-Selector" (:-).
<jra>
Namespaces are being added to HTTP, and I don't think there are so many
changes happening that we can coordinate our headers. Besides, its the use
of the header on a method that is method specific, not the header itself.
The fact that the archery team uses Target-Selector on their method to mean
something else is of no consequence. Its confusing, but doesn't hurt
anything.
</jra>
7. The paragraph about Target-Selector specfies a revision id or
label is
incorrect. The selector "self" cannot be applied to collections on
the path
because its a revision of the collection that's needed, not the
versioned
collection as a whole.
And if so, it will "correctly" return an error (you should be using a
workspace
to look at things in versioned collections).
<jra>
But down-level clients can't do this.
</jra>
Down-level clients won't be issuing requests with Target-Selector headers.
<jra>
We're back to the same issue as above: how does one override the workspace
when the revision requested is in a revision of a versioned collection. You
need the workspace to get the revision of the collection, and the
Revision-Selector to get the revision. You're right, this has nothing to do
with down-level clients.
</jra>
Cheers,
Geoff