- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 5 Oct 2000 00:08:36 -0400 (EDT)
- 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 UTC