Next message: Juergen Reuter: "Re: review of -06 draft"
Date: Fri, 4 Aug 2000 04:22:52 -0700
From: Greg Stein <gstein@lyra.org>
To: ietf-dav-versioning@w3.org
Message-ID: <20000804042252.B19525@lyra.org>
Subject: review of -06 draft
Hi all! Time for me to start working with Delta-V, so I spent a good long
while reading the latest draft. 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.
Review...
2.1: "mutable revisions" is mentioned, but is an advanced concept
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.
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.
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.
6.6: using LABEL/report seems awfully strange. I'd rather see this occur
through a PROPFIND. Call the property DAV:label-name-set
6.6 preconditions: the last paragraph doesn't make sense when the
Request-URL specifies a 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 :-)
6.7.1: there is no DAV:history-report. that line should be removed from the
example.
7 intro: reference to section 6.6.2 for the REPORT method should be to
section 6.7.
7.3 intro: first sentence mentions DAV:checkin-time. should be
DAV:checkin-date.
7.4: DTD says label-set but should be label-name-set
7.4: third paragraph of prose has "DAV:revision tree" a couple times. Should
have a hyphen in there.
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?
9.1: nits, last paragraph. first sentence "one versioned resources" should
not be pluralized. Next sentence has duplicate "of a set"
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.
12.2: reiterate my request for Coded-URIs here
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.
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?
-------------
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/