Re: Compare reports

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 5 Oct 1999 16:26:59 -0400 

Date: Tue, 5 Oct 1999 16:26:59 -0400
Message-Id: <9910052026.AA14317@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <1999Oct05.122000.1250.1342192@otismtp.ott.oti.com>
Subject: Re: Compare reports

Warning: I have not had a chance to think through all the issues
surrounding an interoperable COMPARE report format,
so these opinions are subject to change without notice (:-).

   From: Jeff_McAffer@oti.com (Jeff McAffer OTT)

   <jm>
   As an additional overall question, would it be a good idea to report the   
   revision-ids where relevant?  That is, for changed resources, report the   
   old and new revision-id.  For deleted, report the revision-id of what was   
   there and for added report the revision-id for what is there now.

<gmc/> I'd include the revision-id in the report (seems like the
civilized thing to do :-).  We need to pick some names for these
elements.  Perhaps <D:old-revision-id>  (for D:changed and D:deleted)
and <D:new-revision-id> (for D:changed and D:added).

   I vote for this as the alternative is to do a REPORT, find out that   
   something changed and then do several round-trips to figure out how it   
   changed.  The server likely has this information available to it easily   
   when it was doing the REPORT.
   </jm>

<gmc/> I agree.

   What is the form of the compare report elements (e.g., how does a
   DAV:added specify what was added?)
   Is it different when comparing configurations, collections,
   activities?

<gmc/> Good question.  Since the description of how something was
changed will probably be resource dependent, we probably need a
D:changed-activity, D:changed-collection, etc.

   - For configurations we could report resource-ids that were
   added/deleted/changed or paths relative to the roots of the
   configurations.

<gmc/> I'd go with resource-id's, since the paths could be part
of what is changing, and the ambiguity with multiple paths that
you mention.

   - For activities, ????
   <jm>
   Again, what *exactly* are people expecting here? That is, how do we   
   describe the resources which were changed?  Since activities have no   
   paths or roots, about the best we can do is the resource-id form given   
   above for configs??
   </jm>

<gmc/> I stick with the resource-id.

   - For Workspaces??? (What does it mean to compare to workspaces?)

   <jra>
   What different revisions would be selected?
   </jra>

   <jm>
   Again, this would only be reasonably reported as resource-ids since the   
   workspaces themselves don't have particular roots etc from which we can   
   generate paths.  See also the mutlipath effects noted above.
   </jm>

<gmc/> I'd probably just leave out comparing two workspaces for now.
Perhaps comparing a configuration with a workspace, to say "what revisions
are selected in the configuration that are not (currently) selected by
that workspace".

Cheers,
Geoff