W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

comments on draft-ietf-deltav-versioning-10.1

From: <Tim_Ellison@uk.ibm.com>
Date: Tue, 17 Oct 2000 16:39:51 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <8025697B.00561F6A.00@d06mta07.portsmouth.uk.ibm.com>


The following comments are sent on behalf of a colleague.

Tim

---------------------- Forwarded by Tim Ellison/UK/IBM on 2000-10-17 04:36
PM ---------------------------
Tim,

I have some comments on the 10.1 spec. Most are minor.
The last one---a feature request for MERGE---is substantial.

Please pass my comments along to the mailing list if the issues have not
already been discussed (I don't read the deltav mailing list).

Thanks,

===================

Comments on draft-ietf-deltav-versioning-10.1

section 2.1 p.9

- stray "<big>...</big>"

section 9.2.1 CHECKOUT example p.22

- The example shows that the request-URL "/foo.html" is checked out as a
new working resource named "http://www.webdav.org/repo/wr-157.html". While
it would be mighty
convenient for the server to preserve the ".html" file extension part of
the file name, servers are under no obligation to do so. It would therefore
be more realistic to show the new working resource with a more
representative URL, such as "http://www.webdav.org/repo/wr-157".

section 10.1 DAV:version-tree-report p. 25

"The elements of a DAV:property-report identify...
- element should be "DAV:version-tree-report"

section 13.3 Version Selector Properties

I notice that DAV:version-history is no longer a property of version
selectors. Is this intentional?

section 15.1 OPTIONS p. 42

Remove mention of DAV:predecessor-set from the "merge" item (this property
is now in core versioning 5.2.3).

section 15.1.1 OPTIONS example p. 42

There are two "DAV" response headers.

section 16.2 MKWORKSPACE p.50-1

The specification should not be silent on the semantics of parent
workspaces containing
     - checked-out resources
     - non-versioned members
     - versioned collections members where eclipsing is involved
     - member collections under baseline control (both checked-out and
checked-in baseline selectors)

section 16.5 MERGE p.53-4

Some clients will want to pre-resolve conflicts before doing a merge: they
use the merge preview report to discover where the conflicts are, make the
necessary changes to resolve the conflicts, and then MERGE the results into
the shared workspace. In this way, the client can completely avoid creating
checked-out resources in the shared
workspace. Never having checked-out resources in a shared workspace has
certain advantages, including the ability to baseline any if its
collections at any time.

The current semantics of MERGE does not support this kind of client
particularly well. There is a time window between the merge preview and the
MERGE operation during which another client could change the shared
workspace in a way that would create a new conflict situation. This would
result in checked-out resources in the shared workspace---exactly what the
client was trying to avoid.

For this kind of client, it would be most convenient if there was a
client-supplied merge option (DAV:pre-merged, say) indicating that the
method should simply fail if there are any conflicts.  If the method fails,
the server must not change any of the merge destinations. While this does
not eliminate the window during which conflicts can arise unexpectedly, it
does give a pre-resolving client a simple way to avoid
inadvertently creating checked-out resources in a shared workspace. When
the method fails for this reason, the client knows that it will need to
repeat the normal process to discover and pre-resolve the late-breaking
conlicts.
Received on Tuesday, 17 October 2000 11:41:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT