- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 13 Sep 2001 17:03:31 -0400
- To: ietf-dav-versioning@w3.org
From: Peter Raymond [mailto:Peter.Raymond@merant.com] I am not sure what scope we have for change to the specification (now that it's completed last call), but here are various issues/observations on draft 18: I will get one last swipe at the document when I get it back from the IETF editor (i.e. in the nroff format), so please keep sending me any errors/typos that you find in the document, and I'll fold them into that final editing pass. Section 11.2, the MERGE method does not have pre or post conditions that define what should happen if the DAV:source and the target URL point to the same version of a resource. I am assuming that the MERGE would return a success but basically be a no-op. I'll squeeze an "or is the same as" into the DAV:ancestor-version postcondition. Section 11.2 the DAV:descendent-version postcondition is missing a full stop (period) at the end of the sentence. Thanks for noticing! Will fix. Section 11.3 should the DAV:ignored-preview set include resources that are the same in both the target and source (do not require merging) as well as resources that are not present in the target. It seems like identifying resources which are ignored because they are identical would be a useful thing for this report to return. A client can determine this information by subyracting the various DAV:xxx-preview sets from the original source set. Section 11.3.1 in this example it would be good to show a example DAV:ignored-preview element and to show a element which has multiple resources, eg multiple conflict-previews (more than one resource in the two workspaces that conflicts). The current example is very simple and MERGE is quite complex. We are planning on creating a "scenarios" document which will have more realistic examples of all the methods, and this would be a good place for this information. Reading section 11 it implies that when DAV:source is a workspace (or collection) and the target URL is also a workspace (or collection) if a VCR is found in the source collection but not in the target it is ignored and not added, this seems odd. Why is this? Surely the file should be added to the target collection. It could be, but if the owner of the target workspace has just explicitly deleted the VCR that referenced the VHR of the version, to recreate that VCR as a result of the merge would be wrong. Similarly, if all of those VHR's were moved into a different baselined collection (not visible in the target workspace), to recreate them in the collection they were just moved from would be wrong. The VERSION-CONTROL method can be used to create multiple VCRs pointing to the same version history (provided they are not in a workspace). How would this affect MERGE? Imagine a collection containing multiple VCRs (which DAV:checked-in pointing to potentially different versions) of the same VHR. What would happen when a MERGE request was carried out on the collection? Which VCR would be the target? It would be ambiguous, and the result would be server defined. There is no "right" thing to do here (sometimes you might want just one, sometimes both, and sometimes just an error message). Finally, section 10.2 defines a "Collection Version Resource" and this says that a collection version captures bindings to VCRs. But later in section 14 a version controlled collection is defined as having bindings to version histories (VHRs). I think section 10 is misleading and section 14 is correct. Where in section 14 does it say that a version-controlled collection has bindings to version histories? A working collection has bindings to version histories, but a version-controlled collection has bindings to version-controlled resources, not version histories. Note that a collection version is very different from a version-controlled collection (just as a version is very different from a version-controlled resource). Cheers, Geoff
Received on Thursday, 13 September 2001 17:04:04 UTC