Next message: Geoffrey M. Clemm: "Re: cache control"
Date: Wed, 6 Sep 2000 09:24:23 -0400 (EDT)
Message-Id: <200009061324.JAA26403@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Review of 07 Core Versioning Updated
From: Tim_Ellison@uk.ibm.com
<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.
Done.
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.
I prefer "version history" because it would be natural to infer that
a "versioned resource" should be what replaces a versionable
resource after it has been placed under version control, when in
fact what replaces a versionable resource is a "version selector".
There is no such potential for confusion with the term "version history".
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>
The DAV:version-name property has been changed to be a revision property
(Boris pointed this out in an earlier message as well). I agree with Tim's
reasoning as to why DAV:auto-version should remain on the version selector
and not the revision.
<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.
Done.
<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.
DAV:checked-out is not necessarily a predecessor, so saving it would
probably cause people to mistakenly use it in the way you describe
above.
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 ;-)
I'll leave it the way it is, since Tim sees a use for it.
<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.
The concept of a version history is in core, but Chris did not want to
require that a core server actually allocate URL's for them.
There is one reference to DAV:version-history in core which I will move
to advanced.
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?
I agree with Tim that this is appropriately handled as unprotected live
properties. A server will have to know that these properties are to be
handled in this special way, so they have to be live.
<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.
Yes, we should be consistent, so I'll use "undefined" consistently
(no need to bring the concept of a "server" into this issue).
<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>
Yes, that is how I remember the discussion as well.
<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.
I agree that the section requires careful reading, but I don't think
it would be simplified by splitting it into two methods.
Currently, the result of a successful VERSION-CONTROL request is that
there is a version selector resource at the request URL. I think that
having a single request to achieve this post-condition is appropriate.
<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?
Yes, we need this restriction to ensure that clients can interoperate
with workspace based clients, which use the request-URL to name the
working-resource.
<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>
Yes, although UNCHECKOUT is like DELETE in core versioning, the additional
postconditions in advanced versioning make the two operations significantly
different.
<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 ...'
I'll change this to use Tim's wording.
<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')
I'll add a statement that the Depth header can be used with the REPORT method.
<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>
Yes, the key motivation for a REPORT method was omitted, namely, that
the REPORT method lets you modify the contents of the report by additional
elements in the REPORT request body (unlike PROPFIND). I'll fix this.
Jim and Tim, thanks for the review and the review of the review,
respectively!
Cheers,
Geoff