Next message: Tim Ellison: "Minutes from the Working Group Meeting, 2-Aug-00"
Date: Mon, 7 Aug 2000 16:41:41 -0400 (EDT)
Message-Id: <200008072041.QAA08088@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: review of -06 draft
From: Greg Stein <gstein@lyra.org>
Hi all! Time for me to start working with Delta-V, so I spent a
good long while reading the latest draft.
Thanks, Greg!
There are a number of points below. I also wanted to say that I
just read the IETF meeting notes and am *very* happy that revisions
(and working resources for them) will be able to occur in multiple
activities. I view an activity as a "change set in progress" and it
is entirely reasonable that two people may want to work on the same
resource.
Just as a warning though, many servers will not let you work on the
same resource in multiple activities, because this entangles those two
activities, making it impossible to safely merge either of them into
another workspace without the other.
Review...
2.1: "mutable revisions" is mentioned, but is an advanced concept
Yes, we've got a couple of those forward references (the other is a
reference to multiple predecessors, which is advanced versioning
functionality). We tried to limit the forward references to
statements that would otherwise be false without that reference.
5.2: can we use a Coded-URI in the DAV: header? there was a
discussion on the main list about what kinds of tokens may be
inserted. There seemd to be a consensus that a Coded-URI was
fine. I'd like to see the same used for Delta-V to ensure
uniqueness. Specifically, return something like:
DAV: 1, 2, <DAV:core-versioning>
There are two alternatives to Coded-URL, but I find them less
favorable:
1) the RFCs get to use plain names; private extensions must use
Coded-URIs to ensure uniqueness 2) private extensions are not
allowed; server should return a private header.
For (1), I find the classification of "who gets to use plain names"
a bit much and would prefer similarity. For (2), this could get a
bit ugly as clients will need to begin looking for multiple
headers; also, defining a private header that is unique is harder
than using a Coded-URI.
The coded-URI form is fine with me, so I'll make that change unless
someone objects.
5.4 and 5.6: if "mutable revision" is left as a core concept, then
these must allow a PUT or PROPPATCH to occur if the revision can be
mutated. If mutable revisions are only an advanced concept, then
the discussion should occur there. IOW, the draft cannot say "the
PUT MUST fail" unilaterally. In some cases, it *will* be allowed.
A mutable revision can only be changed by checkout/checkin (not
directly by PUT or PROPPATCH).
6.5 preconditions, third para: it mentions if the request-URL is
write-locked, then tokens must be provided. Well... a Depth: header
can be provided on a Set-Target, so a mention must be made about
providing tokens for write-locked child resources, too.
In most cases, we've used the fact that a "depth operation is that
operation applied to each member" to implicitly define the semantics
when a depth header is present, except for cases where we felt there
might be confusion. In this case, I believe the semantics are clear,
but if you feel people might be confused, then we could add some
words.
6.6: using LABEL/report seems awfully strange. I'd rather see this
occur through a PROPFIND. Call the property DAV:label-name-set
Eric asked for this too. I'll make the change if nobody objects.
6.6 preconditions: the last paragraph doesn't make sense when the
Request-URL specifies a revision.
This is the "If DAV:remove is specified, the specified label MUST
select that revision"? Why doesn't that make sense (i.e. this says
that you can't remove a label from a revision if that label is not on
that revision).
Also, how does DAV:add operate when applied to a revision URL? I'd
say something like "... the specified label MUST NOT select a
revision of the versioned resource corresponding to the revision
specified by the Request-URL." a bit wordy and awkward, but that's
my first take :-)
Do you dislike the phrase "the revision selected by the label"? This
phrase is consistent with the use of the term "Target-Selector" that
allows you to specify a label to select a particular revision. I'd be
happy to change, but I think I'd like something better than your first
take (:-).
6.7.1: there is no DAV:history-report. that line should be removed
from the example.
Yes, that should be DAV:revision-tree-report (it *used* to be called
DAV:history-report :-).
7 intro: reference to section 6.6.2 for the REPORT method should be
to section 6.7.
Done (haven't hit the F9 key for a while :-).
7.3 intro: first sentence mentions DAV:checkin-time. should be
DAV:checkin-date.
Fixed.
7.4: DTD says label-set but should be label-name-set
Fixed.
7.4: third paragraph of prose has "DAV:revision tree" a couple
times. Should have a hyphen in there.
Fixed.
8.1, Merging: third sentence states "the merge changes the target
of the versioned resource to be the specified revision." However,
this statement would be incorrect if it is possible to specify
*two* revisions, each being a descendent of the target, to the
MERGE operation. I'm not sure if this is possible, but maybe with a
multiple checkout enabled?
Currently, there is no way to specify multiple revisions of the same
revision history to be merged at the same time (i.e. all the possible
arguments to merge select at most one revision per revision history).
9.1: nits, last paragraph. first sentence "one versioned resources"
should not be pluralized. Next sentence has duplicate "of a set"
Fixed.
10.2.3, 10.2.4, 10.2.5: these properties should be allowed to be
protected. Some statement to that effect should be made. 10.3.4:
some of these should also be allowed to be protected, similar to
their corresponding Revision properties.
I'm not sure what you mean by "should be allowed to be protected".
"Protected" means that a PROPPATCH to that property MUST fail, so for
any server to be able to allow PROPPATCH to update a property, it
cannot be defined as being protected. A particular server is of
course free to be more restrictive (e.g. in the case where the
implementation only allows a particular value for these properties).
12.2: reiterate my request for Coded-URIs here
See above.
12.6, 12.7: I read Jim Amsden's review stating these should always
fail. Maybe there was some missing context, but it *must* be
possible to move, copy, and delete versioned resources. Part of
this effort involves management of the URL namespace -- not just
management of changes to resources.
Yes, COPY/MOVE/DELETE must all be supported for versioned resources.
13.3: MERGE should not demand a target workspace. I'd like to merge
an activity directly against the versioned resources. Is there a
rationale for requiring a workspace, which I don't understand?
We can loosen that up to allow merging into an arbitrary collection,
rather than just a workspace. This was also requested at the working
group meeting in Pittsburgh. I will make this change if nobody
objects.
-------------
That's all. The draft is looking quite good. I can tell there was a
lot of thought put into the clarification of the different resource
types and how they all interact. It certainly clarifies things.
Great! And thanks again for the thorough review.
Cheers, Geoff