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

Re: A bit more on MERGE

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 5 Oct 2000 00:08:36 -0400 (EDT)
Message-Id: <200010050408.AAA08816@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: "Lisa Dusseault" <lisa@xythos.com>

   "The MERGE method is responsible for determining"... I suspect this should
   read "The server is responsible for determining", or possibly, "The MERGE
   method contains the information necessary to determine".

What is the difference between "The MERGE method is responsible" and
"The server is responsible" ?  

   How can a collection of version selectors be a destination? Are they _all_
   the destination?

A collection can be the Destination, and then it is up to the MERGE
method to determine for each version identified by the request URL,
which version selector in that collection should be the merge
destination of that version.

   How can a request-URL identify a version?

Every version has a URL (assigned to it by the server).  Or the
request URL can identify an activity or a baseline, in which case all
versions in that resource's DAV:version-set are merged.

   Rather than have the request-URL be an activity, I'd prefer to see the
   activity named in the body of the MERGE.

That would be fine with me, and then we could have the request-URL
identify the merge destination (and not have to use the Destination
header).  Does anyone else care?

   Is the server supposed to use the values of the "merge-set" and
   "auto-merge-set" properties when performing the MERGE?

No, the MERGE is responsible for setting (or updating) the merge-set
and auto-merge-set properties.  I'll update the protocol to make this
clearer.

   (I'm still confused about whether the merge-set and auto-merge set
   properties are supposed to be cleared after a MERGE, to allow a CHECKIN, or
   whether they should stay around for information).

The client is required to clear the merge-set and auto-merge-set
(normally, moving those URL's to the predecessor-set), before that
version selector can be checked in.  I'll add some sentences to
emphasize this in the MERGE method introduction.

   "If the merge destination is a working resource, the request version is
   added to the DAV:merge-set"... Why is it added, if the client intentionally
   left it out?

The server sets it, not the client.  The purpose of the MERGE
operation is to have the server, not the client, figure out what needs
to be merged.

   What is "the request version" -- I thought there could be
   several according to the introductory paragraph on MERGE?

This are a set of request versions.  This sentence indicates what
is done with each of them.

   And, do you mean
   that the "request version", whichever it is, is added to the DAV:merge-set
   property only, or that it is actually added to the set of documents being
   merged?

What does "actually added to the set of documents being merged" mean?

   "If the merge destination is a version selector whose target is neither a
   descendant nor an ancestor of the request version...  The merge destination
   URL MUST appear in the DAV:update-set".  But I don't see this done in the
   example.  Perhaps along "descendent or ancestor" you allow "parent"?

Each merge destination URL will be some member of the collection identified
by the Destination  header (as is the case for the example).  What did you
expect to see in the example that wasn't there?

   I finally noticed here that activities are supposed to have sub-activities.
   Please specify how this is done.

By PROPPATCH'ing the DAV:sub-activity property of the activity
(it's not a protected property).

   I couldn't find where activities are
   updated, or linked to sub-activities.

They are updated by CHECKIN, and can also be updated by PROPPATCH'ing
the DAV:activity-set of a version, if the server allows that.

Cheers,
Geoff
Received on Thursday, 5 October 2000 00:09:05 GMT

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