W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Various comments...

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 13 Sep 2001 17:03:31 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8ABCA@SUS-MA1IT01>
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

   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

Received on Thursday, 13 September 2001 17:04:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC