Re: comments on draft-ietf-deltav-versioning-10.1

   From: Tim_Ellison@uk.ibm.com
   [The following comments are sent on behalf of a colleague.]

Tim: Thanks to both you and your colleague for some great comments!
(You aren't supposed to shoot the messenger, but I assume you can
thank him? :-)

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

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

   Comments on draft-ietf-deltav-versioning-10.1

   section 2.1 p.9

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

I'll forward this to the Microsoft Word developers (:-).  It won't
show up in the ASCII text that is the "official" version.

   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".

Well, if the server is expecting standard Web browsers to let you look
at the version resource directly (i.e. other than through a version
selector), they had better stick the .html (or at least, .htm :-) on
the end.  It's certainly up to the server, but I didn't want the
example to set a bad example (:-).

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

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

Will fix (thanks for catching that!).

   section 13.3 Version Selector Properties

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

Yes, that is one of the batch of live properties that a server is
allowed to decide whether or not to reflect/copy the underlying version
property in the version selector resource.  A client that wants to get
the info in one request can use a DAV:property-report.

   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).

Good point.  Will fix.

   section 15.1.1 OPTIONS example p. 42

   There are two "DAV" response headers.

That's on purpose.  You are allowed to have multiple headers
of the same kind as long as they take comma separated values
(and the effect is just as if you had all values in one line).
I thought this was clearer than the alternatives (and reminds
folks of this bit of HTTP triviata :-).

   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)

You are correct that all this has to be specified (and isn't).  Since
it looks likely that anyone that is implementing workspaces will also
be implementing baselines, I think the best (simplest) approach is to
just to use existing baseline functionality to initialize a workspace,
and get rid of parent workspaces.

In particular, if a workspace is under baseline control, just use
SET-TARGET to set that workspace to a baseline from some existing
workspace.  Since a baseline does not contain checked-out resources,
non-versioned members, or eclipsed members of versioned collections,
none of these questions arise.

Any objections?

   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.

That all sounds sensible to me.  I'd probably name the argument
DAV:no-checkout if that's OK with you.  Anyone object to adding
this feature?

Cheers,
Geoff

Received on Tuesday, 17 October 2000 17:19:25 UTC