Next message: Tim_Ellison@uk.ibm.com: "cache control"
From: Tim_Ellison@uk.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <80256952.003A8DA3.00@d06mta07.portsmouth.uk.ibm.com>
Date: Wed, 6 Sep 2000 11:39:24 +0100
Subject: Re: Review of 07 Core Versioning Updated
<jim>
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!
</jim>
<tim/>here here
<jim>
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 ********
</jim>
<tim>
I agree that the version name should be on the version, not the version
selector. I also agree that auto-version should be on the version selector
since it is nore likely to be useful based upon how the resource is
accessed (i.e., the path) rather than the resource itself.
</tim>
<jim>
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.
</jim>
<tim>
I agree that there is a box missing.
===VERSION-CONTROL==>
|
| +----+ History
Resource
| | |
http://repo.webdav.org/his/31
| +----+
| |
| |
+----+ | +----+ +----+ Version
Versionable | S1 | | | -----------> | S1 |
http://repo.webdav.org/his/32/rev/1
Resource +----+ | +----+ +----+
http://www.webdav.org/foo.html Version
Selector
http://www.webdav.org/foo.html
<tim/>
<jim>
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.
</jim>
<tim/> I don't mind really, but I can see rationale for having it on a
selector (as above).
<jim/> 3.3.3: DAV:version-name describes a property of a version, not a
version
selector.
<tim/> Definitely agree.
<jim>
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?
</jim>
<tim/> Actually, I quite like the extra element, so I can sneek extra check
out info in there ;-)
<jim>
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?******
</jim>
<tim/> Servers would be free to implement unprotected live properties to do
this -- or are you suggesting users defining their own (dead) properties?
<jim/>5.7 Is undefined the same as server defined? Should we use that term
throughout?
<tim/> FWIW I think of undefined as meaning server defined. It is
undefined by the spec. and therefore cannot be relied upon across compliant
servers.
<jim>
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.
</jim>
<tim>
As I recall the discussion, all of (1) - (3) were offered as reasonable
interpretations of LOCK with a Target-Selector, and that is why the spec.
was to say the result is undefined. It will create inter-op problems if
people rely on it, but there are alternative ways that circumvent the
problem and work to spec.
</tim>
<jim>
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.
</jim>
<tim/>I agree that this section requires very careful reading.
<jim>
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.
</jim>
<tim/> If the request URL was a Version URL where would the working
resource be created?
<jim>
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?
</jim>
<tim>
Unless I am missing something, there is a significant difference between
UNCHECKOUT and DELETE on a working resource. When I UNCHECKOUT a working
resource the request URL target is replaced by a version selector that
selects whatever was checked out to create the working resource; however,
if I DELETE a working resource the request URL is 'unbound' from its parent
collection (and the versioned resource is still left in a checked out
state).
</tim>
<jim>
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.
</jim>
<tim/> I read this as 'when using a DAV:version element body ...'
<jim>
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?
</jim>
<tim/> probably (for all but 'tree')
<jim>
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.
</jim>
</jim>