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

Review of draft-08

From: Jim Amsden/Raleigh/IBM <jamsden@us.ibm.com>
Date: Thu, 5 Oct 2000 14:20:07 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OF58BA334B.0833CA9D-ON8525696F.00608715@raleigh.ibm.com>
   Section 5.2.2/3/4, DAV:predecessor-set, DAV: successor-set,
   DAV:checkout-set
   Please clarify that for "core" versioning support, since in "core" there
is
   no way to fork or merge, that the "predecessor-set" and "successor-set"
   will
   only contain one element.  Right?

In core versioning, there is no way to merge, but you can fork
(just checkout and checkin a version that already has a successor).
And although a core client cannot create a merge, it needs to be
prepared to deal with a merge created by an advanced versioning client.
<jra>
If DAV:predecessor-set was unprotected, a core versioning client could do a
manual merge a resource at a time.
</jra>

   Section 5.3, Version Selector Properties
   How does a client definitively figure out if a URL points to a "Version
   Selector", a version history, or a regular resource?

Wouldn't it find out what it needs to know by asking the resource
what methods, live properties, and reports it supports?
<jra>
This logic could easily be encapsulated in a higher-level client API too.
</jra>

The purpose of VERSION-CONTROL is to create a version selector at the
request URL.  This can be done either by creating a new version
history whose initial version is a copy of the resource currently at
the request URL, or by using a version from an existing version history.
In either case, the postcondition is the same, i.e. a version selector
resource will exist at the request-URL.
<jra>
I liked this explanation. Should it be in the spec?</jra>

<jra>Thanks Lisa for an extremely thorough review!</jra>
Received on Thursday, 5 October 2000 14:28:38 GMT

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