Next message: Torsten Lenk: "versioning tools"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525692D.00590AF3.00@d54mta02.raleigh.ibm.com>
Date: Mon, 31 Jul 2000 12:12:17 -0400
Subject: Review of 06
I liked the semantic distinction between the target, specified in a
target-selector header and the default-target, defined by a property of the
versioned resource and selected by default if the target-selector wasn't
specified.
It also doesn't seem like the point of SET-TARGET is to
modify the state of the verisoned resource. Perhaps this section
should read: "The SET-TARGET method may be used to set the revision
to be used as the default-target of a versioned resource. The
default-target revision is that revision that will be selected when
the request URL refers to the versioned resource, and no
Target-Selector header is present."
<geoff>
This sounds a lot more complicated than the current definition.
What is the problem with the current definition?
</geoff>
The problem with the current definition is that it doesn't focus on the
point of SET-TARGET. Modifing the state of a versioned resource isn't
what's interesting. The fact that a new default revision is selected is The
description I gave above (quoted) is more complicated because it both
defines the meaning of the SET-TARGET method, and the meaning of having a
default-target (which was defined elsewhere, but not this way).
section 2.2: I don't like the language "will cause the versioned resource
to display the content".... Versioned resources don't display anything by
any meaning of the verb display. The sentence should read "The SET-TARGET
request will cause references to the versioned resource to operate on the
content and properties of the specified revision."
Similarly, section 2.3 second paragraph: "For certain methods, a
Target-Selector request header can be used to make references to a
versioned resource operate on the content and properties..."
Section 3.3.2 DAV:auto-version: should we say "to be effectively proceeded
by a CHECKOUT and followed by a CHECKIN..." to allow servers more flexible
implementations?
3.4.2 reference to merging should be removed - its an advanced versioning
concept. However, this brings up an interesting question. There is no
DAV:single-checkout property on a revision and/or versioned resource, so it
is possible for many users, or the same user, to checkout the same revision
more than once creating multiple successors for the same revision. But
there is no merge method, and the DAV:predecessor-set is protected. So
there is no way to merge these successors back into a single line of
descent. Is it reasonable for the spec to allow "branching" without
merging?
3.2.1 creator-displayname has limited value: can be changed anytime by
anyone, syntax isn't specified, doesn't correspond to a principal. Why
not
use the principal?
<geoff>
The purpose of "creator-displayname" is not to identify a principal
(that's something the ACL protocol will introduce), but just to give
some string that a client can use to print out something (hopefully)
meaningful to the user.
</geoff>
The point I was making is that its the principal (in a DAV:creator
protected property) that's of value, not the display name. The question is,
do we want to specify this property too so we have a more reliable way of
identifying who created a revision, and if so, will we require an
authentication header to specify it on checkin?
3.5.1 DAV:checked-out needs to be DAV:predecessor-set for working
resources
to be consistent with support for advanced versioning merging. Why not
use
the same property for the same function in working resources and
revisions?
<geoff>
The DAV:checked-out property is needed to specify what revision will
be the target when an UNCHECKOUT is performed, while
DAV:predecessor-set determines what the DAV:predecessor-set of the new
revision will be. Note that although the DAV:predecessor-set is
initialized to be the DAV:checked-out revision, the client can change
this (but it can't change the DAV:checked-out property).
</geoff>
UNCHECKOUT works on the working resource, not the revision, and just
deletes it. I still think it would be more uniform, and therefore simpler
for clients, if the DAV:predecessor-set was used for this. But I may not
understand your point above. The DAV:predecessor-set is protected. Did you
mean to do that? That's why I mentioned there no way to merge above.
I do like having DAV:checked-out so we can distinguish between revisions
that were created by checkout, and those created as a result of a merge. It
seems that there is generally a qualitive difference between the two that's
worth retaining.
5. a versioned resource isn't checked out, the target revision is.
<geoff>
Since you issue a CHECKOUT operation against a versioned resource, I
think it makes sense to say that you "check out a versioned resource".
When a Workspace header is used, you cannot issue a checkout against
a revision URL (only against a versioned resource URL), so for
compatibility
between workspace and non-workspace checkouts, it is best to restrict
a checkout to be against a versioned resource.
</geoff>
As a matter of style, I prefer to indicate the method operation on what
actually gets effected. In the case of CHECKOUT, the target URL is the
versioned resource, but its the revision that gets the new successor which
seems to be more to the point. Why can't you CHECKOUT using a revision URL?
Wouldn't the workspace header be ignored in this case, just like the
target-selector header?
------
Section 5, add a second paragraph: "For any request whose request URL
identifies a versioned resource, and no Target-Selector is specified, the
request MUST act as if the state of the versioned resource was a copy of
the revision specified in the DAV:target property of the versioned
resource."
5.1 Specify the status codes (I don't have the WebDAV spec in front of me,
just pick the next available codes).
5.6 Why not auto-version a specific revision given a revision URL. To the
server, this is just the same as resolving a versioned resource and
target-selector or DAV:target to a specific revision and then auto
versioning that revision.
5.7 What's the motivation for having DELETE on a revision or working
resource undefined? The postcondition for UNCHECKOUT is that the working
resource is deleted. Why not allow DELETE to do the same thing? In fact,
why bother with UNCHECKOUT at all? Will leaving this undefined cause
interoperability problems?
5.8 COPY of a revision should never create a versioned resource. Or we
should allow servers to specify if COPY or PUT may create initial revisions
of new versioned resources or not. COPY of a versioned resource should
fail.
5.9 MOVE of a versioned resource should fail.
5.10 Why can't a LOCK request specify a Target-Selector? Wouldn't this be
the usual case when using labels? How would this be semantically different
than locking a revision through any other means (a revision URL or by using
the default target)?
Why is there a checkout element in the entity request body to specify
something that can be easily specified in the request URI or the
target-selector? What if the CHECKOUT request URI is a revision URL and
the
checkout revision in the entity request body is a different revision?
This
seems redundant.
<geoff>
For compatibility with workspaces (which only allow checking out a
versioned resource, not a revision), the request URL for CHECKOUT must
be a versioned resource URL, not a revision URL.
</geoff>
I don't understand. Why is the revision URL in the request body then? How
is this different than having it in the request URL?
DAV:checked-out should be DAV:predecessor-set.
<geoff>
The DAV:predecessor-set is an optional working resource property
introduced by advanced versioning.
</geoff>
No, its specified as a property of a revision in core versioning. The same
property should be used for the same purpose for working resources
(although it could never have more than one entry becuse there's no merge).
6.5 Seems like the Target-Selector header should be able to be used to
specify the target in SET-TARGET instead of an entity request body. This
would help unify target selection.
<geoff>
The purpose of SET-TARGET is just to update the value of the DAV:target
property of a versioned resource. It seems more consistent to always
have the new value be in the request body, rather than sometimes in the
Target-Selector header and sometimes in the request body (you can't
put a revision URL in a Target-Selector header).
</geoff>
But this is the problem. You can specify something in a SET-TARGET that
indicates what target will be selected by default that you can't specify in
a Target-Selector that specifies a specific target. This is inconsistent
and confusing.
7.3 do we want to introduce a "latest" functor for the Target-Selector
instead of using a DAV:latest-checkin-report? Then users can operate on
the
latest revision in a single method.
<geoff>
The Target-Selector header is currently defined as specifying a
label. I believe it is simpler to keep it that way.
</geoff>
But DAV:latest is a common and useful (although somewhat dangerous)
function that we had agreed to include in past versions of the spec,
regardless of the simplicity of the SET-TARGET method or Target-Selector
header.
7.4 How would the client be able to predict what information will come
back
from the DAV:revision-tree-report if the server can arbitrarily decide
which elements to eliminate?
<geoff>
Why would a client need to know? The revision-tree-report contains all
the revisions, so every successor is guaranteed to appear somewhere in the
report, allowing the client to display the tree however it wishes.
</geoff>
Then I don't know what you mean by the server can arbitrarily decide which
elements to eliminate. I took it to mean that a client could not expect all
the revisions to be returned in the report. Maybe I missed what was being
pruned.
Ok, I see it now. The "elements" you referred to are the properties of a
revision, not the revisions themselves, and the ones that can be eliminated
are ones that may have already appeared.
Section 7: refresh my memory, why aren't these reports just live properties
accessed throug PROPFIND? The core reports would seem to be handled just
fine this way.
I don't quite follow the layout of a revision-tree. In the example report,
a revision-tree contains a revision and a nested revision-tree which I
assume represents the predecessors of the revision. But there's also a
predecessor-set. Isn't this redundant?
8.1: Doesn't core versioning need the concept of a History resource too?
Isn't that what's returned by the revision-tree-report?
Core versioning should be (able to be) defined as having a single, default
workspace with no ability to create new workspaces.
Wouldn't activity be used to label the arcs between the revisions rather
than the revisions themselves? That is, the activity names the line of
descent used to create a logical change.
Branch should be in core versioning as it is possible to create them there.
9.1 So a workspace appears in the user's namespace, not as an identifier
specifying what revision of a versioned resource to select? This section is
not clear. Paragraph 2 needs more. Section 11.1 makes it clear. A little
moreintro here might make the document read better.
9.2 the point of baselines is to create a stable version of a workspace so
it can be recreated at some later time. All this stuff about efficiency and
space doesn't seem to be the point.
9.3 Switch paragraph 1 and 2. Paragraph 3 describes the primary use of
activities. Paragraph 1 introduces two unsupported concepts: projects and
constrained branching. These first two sentences didn't compute
particularly well.
9.4 I think we should remove automatic merging.
9.5 public and private are generally used to denote visibility, not
life-time. It seems more intuitive that a versioned collection could
contain members that are versionable resources and versioned resources. One
can depend on getting a particular revision of the versioned resource, but
the versionable resource contents may change. It seems like we're mixing
concepts here. The fact that some of the members of a collection reference
versionable resources doesn't seem to have anything to do with its
membership in a collection, versioned or not. We need to think this one out
some more.
10.2.4 indicate that the user would have to checkout the latest revision
of the resource, and merge his changes in order to recover from such a
failed checkin. Not clear how this would be done as it would require two
working resources for the same versioned resource in the same workspace.
10.3.4 What's the relationship between the checked-out and merget-set
properties of a working resource, and its predecessor-set?
10.4.4 Where did this come from? It seems unreasonable to have a resource
"half versioned". What's the use case?
10.5.2 When many workspaces are merged into a workspace, it is unclear
which one is it's parent.
10.5.3 I don't think we need parent/child relationships between workspaces.
The relationships are in the successors and predecessors of revisions in
the workspaces.
10.7.2 dependent-activities better describes the role being played.
11.1 & 12: I like the way this worked out.
12.2 What are the possible combinations? e.g., can't have baseline without
workspace. Is there a hierarchy?
12.3, 12.4: could be an error instead of undefined?
12.8 Why not have the server create the history revsource as a side effect
of VERSION on a versionable resource? One can get the history URL from the
created revision using the default workspace. VERSION needs to take a
workspace header to indicate that the new versioned resource should be in
that workspace. I had a really hard time getting my head around what's
happening here. Too many if-thens with all possible combindations of
request URL and version element. VERSION on a versionable resource always
creates the history resource and versioned resource. Other versioned
resources to this same history resource are created by binding to the
initial versioned resource.
What's the relationship between the target-selector header and the
workspace header? Does the target-selector header override the workspace
header?
12.9 first precondition: does this mean that if the resource is already
checked out in that activity, then the checkout fails? This used to be the
case indicating more than one user cannot be working on the same activity
on the same resource at the same time. If this wasn't true, then it would
be possible for different branches of the same revision to be checked out
in the same activity which would result in a violation of the first
precondition? If so, does the DAV:checkout-branch apply when using
activities?
postcondition 2, it would be nice if this were true for core versioning too
where the "default workspace" was "/".
second to the last postcondition: ... the DAV:activity. if any, of the
checked out revision is used.
postcondition 1: don't know why this is different from core.
13.1 See comments on MERGE. Merge should take a workspace too, and merge
the members of the workspace into the merge destination workspace. Then
MKWORKSPACE doesn't need a parent workspace (which implies a hierarchy that
isn't there).
13.3 the request URL should be able to be a workspace too in order to merge
one workspace into another. 7th paragraph, last sentence, a new versioned
resource should be created in the destination workspace, and the revision
included. This would be how new resources are added to a workspace from
some other workspace, revision, activity, etc.
Last precondition: what if one of the conflicts results in a CHECKOUT
failure but others are OK? Is it a best effort operation, or does the MERGE
fail? Note that the user could fix the problem with the checkout and do the
merge on that single resource at some later date. Note also that there's no
reason to not continue doing the merge from source to destination untill
all the conflicts are gone. So it looks like it would be OK to do best
effort.
How are versioned resources removed from a workspace?
13.4: will this be supported by many servers? Do we need to include it? Is
it likely that after unversion on some servers, it will be impossible for
them to retain the history resource?