FWD: Questions on the 02 versioning protocol draft

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 13 Aug 1999 14:29:54 -0400 

Date: Fri, 13 Aug 1999 14:29:54 -0400
Message-Id: <9908131829.AA26052@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: FWD: Questions on the 02 versioning protocol draft


   From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
   Organization: Object Technology International Inc

   I writing up the REPORT method and making an example for MKRESOURCE I   
   came up with a fair number of questions...

   1) are compare and conflict reports deep?  That is, if the specified   
   resource is a  versioned collection, does the report include all   
   transitively reachable resources?

   2) If #1 = yes, when we hit a non-versioned resource during the   
   traversal, what happens?  I suggest that the report not report on   
   non-versioned resources.

   2.5) If #1 = no, why?  How would I, for example, find ALL conflicts.

   3) Observation: if conflict reports are transitive then when we hit a   
   versioned collection which is ambiguous (i.e., a conflict) the report   
   cannot continue the traversal of its the collection's children as it is   
   ambiguous which set of children should be followed.

   4) sections 5.2.2.2/5 talk about having activities in configurations.   
    This is confusing.  What does it mean to have an activity in a   
   configuration?

   5) how does one create a configuration?  MKRESOURCE is the likely   
   candidate but it is expecting a Request-URI.  What is this supposed to   
   be?  Is it possible to have MKRESOURCE return a URL in its response body?   
    This would allow servers to put configurations wherever it wanted them   
   and tell users where they were. Alternatively, the only way to make a   
   config is to deep check-in a collection and then access its baselines   
   property.  This seems circuitous and reduces the usefulness of   
   MKRESOURCE.  Note that I am looking at configurations as "metadata" which   
   should generally not appear in the normal user URL space.

   6) How does one add something to a configuration?  That is, what method   
   with what headers/body should be used to get VR45.67 (revision 67 of   
   versioned resource 45) into a configuration?  Similarly, how is the   
   currently selected resource at http://foo.com/index.html added to some   
   configuration?

   7) What are the semantics of the DAV:needed-configurations property of   
   configuraions?  Are these needed configs transparently traversed by the   
   workspace if the parent config is (indirectly) in the RSR?  Do I have to   
   manually add to the  needed configs? If so, how do I do that?  If it is a   
   collection, what are the member names?  If not, then what?  Is it   
   auto-gen'd at deep checkin time?  If that is true, then how does the   
   server detect that some child (of the root being checked in) has a config   
   that should be put in the needed list?  Is it possible ot have a baseline   
   of this child automatically created?  How does this interact with the   
   DAV:auto-version revision property?

   I suspect that this is an orthogonal concept and that we need another   
   property on collections which says whether or not they should be   
   baselined if a parent is being baselined and they have (transitively)   
   changed since the last baseline.

   8) The MKRESOURCE description is confusing in its treatment of existing   
   resources.  As I understand it, any existing resource is, by default,   
   deleted and the new resource put in its place.  If the overwrite header   
   is specified, the existing resource is somehow morphed into the resource   
   you want?  The last two paras of the section are contradictory.  One says   
   there are no interactions but the existing resource is delete (an   
   interaction if you ask me) and the next says that the existing one is not   
   delete but morphed (i.e., an interaction but not a deletion).

   9) What resource types can be created with MKRESOURCE?  What are the   
   actual resource type names for our new resources (configuration,   
   versioned resource, versioned collection, etc.)?

   10) The use of the history-uuid property is not clear.  Is it a GUID?   
    Could/should it be something simpler like a repository-relative id   
   (i.e., why is it itself universally unique)?


   Jeff