Next message: Clemm, Geoff: "draft-ietf-deltav-versioning-06"
Date: Fri, 14 Jul 2000 09:06:06 -0400 (EDT)
Message-Id: <200007141306.JAA17674@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Review of core versioning spec 05
Thanks for the review, Jim!
From: jamsden@us.ibm.com
Abstract: should this mention configurations or baselines. This is an
important concept to include.
Done.
mutable revisions are not in core versioning?
Correct. Since the main distinction between "core" and "advanced" is
that "advanced" is optional, it seemed sensible to make them clearly
part of "advanced".
default target is defined, but not target.
Good point! The protocol only uses the term "default target"
(i.e. never uses just plain "target"), so we can simplify things by
just calling it the "target" (and calling the property the "DAV:target").
2.2: a versioned resource does not display content & properties of
a revision.
Sure it does ... at least, that's what the spec says (:-).
Or was it the term "display" that you didn't like?
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."
This sounds a lot more complicated than the current definition.
What is the problem with the current definition?
2.3 last sentence of 1st paragraph: ... can be given to two revisions
from...: remove two, it can be given to any number of revisions.
Done.
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?
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.
Don't we think authentication should be required to
check something in?
Yes, but that's something the ACL protocol needs to take care of.
3.3.1 The default revision could be indicated by:
- an isDefault boolean property on a revision
In advanced versioning, you can have different versioned resources (in
different workspaces) associated with the same history resource but
each with their own target (in fact, that's the main point of having
multiple workspaces). If you tried to use a boolean property on
a revision, that would cause every versioned resource for a given
history resource to have the same target (not what is wanted).
- a "default" label functor on a revision
- a label on the versioned resource (let the server figure out what
revision has the label)
This would eliminate one use of server generated URLs.
You don't want to force a server to implement the versioned resource
target as a label, because the "target" property can be implemented
much more efficiently if it does not require a label update.
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?
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).
5. a versioned resource isn't checked out, the target revision is.
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.
5.2.1 Add versioning methods to OPTIONS Allow: response.
In general, only some of the versioning methods will be returned in
a particular Allow: response. In this example, the resource must be
a "versionable resource" (not a versioned resource), so the only
versioning method that can be applied is VERSION.
5.6 Do we need to define meta-data on properties that allows them to be
protected and able to be changed without creating a new revision? Users
might want to be able to define their own properties with this kind of
behavior.
What resource would these properties be associated with? If they were
associated with a revision, changing that property would mean changing
that property in every versioned resource whose target is that revision.
This would effectively eliminate the possibility of an efficient
distributed implementation of workspaces.
5.10 Then what are the semantics of LOCK on a revision, versioned resource,
etc.?
Just the standard semantics ... the name, content, and properties
are protected by the lock.
6.1 Do we want to return a 20x status code if VERSION is applied to an
already versioned resource just to indicate to the client that this was the
case?
I'm happy either way ... what do folks think?
6.2 A CHECKOUT request is applied to a revision, not a versioned resource.
If the request URL is the versioned resource, then the target revision is
selected (either the default-target, or the target selected by the
Target-Selector header).
To be compatible with workspace semantics, the CHECKOUT request must be
applied to a versioned resource URL, not to a revision URL. So I believe
it is better to describe CHECKOUT as being applied to a versioned resource.
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.
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.
DAV:checked-out should be DAV:predecessor-set.
The DAV:predecessor-set is an optional working resource property
introduced by advanced versioning.
6.3 405 The request-URL did not identify a working resource
Done.
What does it mean to checkin with a Target-Selector header? Does the
Target-Selector header have to be the working resource URL?
Fixed (CHECKIN cannot take a Target-Selector header).
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.
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).
6.6 Are labels already available in an existing report?
No.
Having LABEL do
editing and reporting complicates the method with unrelated functionality,
and confuses the entity response.
That's the way it was originally marshalled in the LABEL method.
I'd be happy to introduce a label REPORT instead, if that what folks
prefer.
7.1 How can the DAV:successor-report be applied to a versioned resource?
Versioned resources don't have successors and predecessors.
It returns the successors of the target of the versioned resource.
The report returns server generated revision URLs. These will likely not be
very meaningful to the client who would prefer the versioned resource URL
and a label. How will a client be able to display this more meaningful
information in a printed report?
By listing the labels on that revision, and deciding which of those labels
to use. Since a revision may have no labels, the server cannot in general
use a label to identify revision.
7.2 Again, how can the DAV:checkout-report be applied to a versioned
resource? Do you mean using a versioned resource URL and Target-Selector
and the method applies to the default-target if the Target-Selector isn't
specified?
Yes.
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.
The Target-Selector header is currently defined as specifying a
label. I believe it is simpler to keep it that way.
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?
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.
I'll try to get an 06 draft submitted today with Jim's changes.
Thanks again for the review, Jim!
Cheers,
Geoff