Next message: Tim_Ellison@uk.ibm.com: "Re: Review of 07 Core Versioning Updated"
To: ietf-dav-versioning@w3.org
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
Message-ID: <OFF1A273E2.5D357AE0-ON85256951.00620159@raleigh.ibm.com>
Date: Tue, 5 Sep 2000 13:55:24 -0400
Subject: Review of 07 Core Versioning Updated
Here's my review of 07 core versioning. It looks like a lot of stuff, but
really nothing all that important. I don't feel all that strongly about
most of the suggested changes below, but just wanted to make sure they
were considered. Looks like we're making good progress getting to last
call. Many thanks to Geoff for working so hard on the spec and dealing
with all these comments!
Abstract: We say something about clients, but not servers. Insert before
"WebDAV Versioning includes:", WebDAV Versioning will also facilitate
client access to many existing versioning repository managers by providing
a standard access protocol.
We have a Versionable Resource, but no Versioned Resource, although the
VERSION-CONTROL method does say it creates a version controlled resource.
I would like Versioned History to be Versioned Resource. It seems more
natural to say the version of a versioned resource created from a
versionable resource.
Since VERSION-CONTROL can create multiple version selectors for the same
version, DAV:auto-version and DAV:version-name (and DAV:version-history
for advanced) go on the version, not the version selector. In particular
the DAV:version-name is like a server assigned label and labels are on
versions, not version selectors. DAV:auto-version could make sense on a
version selector ********
2.1: The diagram would seem to indicate that after VERSION-CONTROL,
foo.html is bound to the version history resource, not the initial
revision. Perhaps it needs to show a separate version history resource
that points to the initial revision. It might be helpful if the diagram
showed version history and version URLs too.
3.3.2: DAV:auto-version could be different on different version selectors
of the same version. DAV:auto-version should be on the version, not the
version selector.
3.3.3: DAV:version-name describes a property of a version, not a version
selector.
3.5.1: If we kept DAV:checked-out on a version as well as putting the href
in the DAV: predecessor-set, those of us who want to distinguish between
predecessors created from CHECKOUT and those created by MERGE can do it,
while those that don't care can ignore the DAV:checked-out property.
Wouldn't that satisfy everyone? It might be hard to implement too as many
servers may not have the ability to save it.
3.5.1: Why not just <!ELEMENT checked-out (href)>? What's the additional
version element for?
DAV:version-history for a version and working resource should be in core
since core includes the notion of a version history resource. See 6.2,
last post-condition.
5.6 We had talked in the past about having certain properties that could
be changed without creating a new version. These are often state
properties used for document management. Should we consider this
functionality? Or should these be properties of some unversioned resource
with a reference from the version so we can stay completely out of the
document management space?******
5.7 Is undefined the same as server defined? Should we use that term
throughout?
5.10. This is going to create a lot of questions. An explanation is
required. Is it because the version selector itself is locked, not the
version? There are a number of potentially useful semantics: 1) label
lock, 2) putting lock on label and version selector, 3) putting lock on
version selector ignoring the target selector. Consider defining this so
that method acts on the selected version. This should be how all uses of
the target-selector header operate.
6.1 VERSION-CONTROL seems a little overloaded. It does two very different
things depending on the presence of the entity request body and the types
of the various arguments. Consider splitting into two methods. (Note that
if we can unify version selector and bind semantics, then this dual role
goes away). First paragraph should indicate that VERSION-CONTROL either
puts a versionable resource under version control, or creates a new
version selector for a particular version.
6.2: Why can't CHECKOUT request target URL be a version URL? Why does it
need to be in a request body? Precondition #2 wouldn't be needed if the
target URL could be a version URL.
6.3: consider copying DAV:checked-out property from working resource to
version on CHECKIN as well as copying to the DAV:predecessor-set.
6.4: I don't see anything in the post-conditions for UNCHECKOUT that would
indicate it is anything other than a DELETE. Do we still need UNCHECKOUT?
6.5: 2nd sentence of 2nd paragraph: "Use of a version element...", Do you
mean applying the SET-TARGET method to a version URL, collection or not?
Version element isn't defined.
6.6: Post-conditions: add that removing a label has no effect on version
selectors that may have had their targets set using that label.
7: does it make sense to allow Depth on versioning reports?
7: The distinction between REPORT and PROPFIND is pretty weak. A live
property could be anything, including a value that depends on the state of
other resources, the server itself, etc. Available reports could just be
live properties. We should consider this if there's any pushback from the
community. We should also provide a little more motivation for why we
didn't use PROPFIND, or use it if we can't find any.