Next message: Geoffrey M. Clemm: "Re: a few nits on the I-D"
Message-ID: <3906C56A7BD1F54593344C05BD1374B10D9E0A@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: ietf-dav-versioning@w3.org
Date: Mon, 7 Aug 2000 10:48:54 -0400
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.
A third alternative is:
3) A plain token appearing in the DAV:header is equivalent to a coded
URI in the DAV: namespace, i.e. "xxx" is equivalent to "<DAV:xxx>".
This allows us to make sense of the current "1" and "2" tokens that the
DAV: header is required to allow as values.
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
Done.
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, I haven't completed my response to Jim's review, but part of the
response is that 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