Re: Compare reports
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Tue, 05 Oct 1999 12:24:36 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: jamsden@us.ibm.com (jamsden)
Cc: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Oct05.122000.1250.1342192@otismtp.ott.oti.com>
Date: Tue, 05 Oct 1999 12:24:36 -0400
Subject: RE: Compare reports
<jm>
I don't think I was very clear in my initial question. I am looking for
very specific details here. There "could" be lots of different formats.
The problem is coming up with a set which are consistent and coherent.
What *exactly* do we think the reports will look like? See below for
some examples.
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.
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>
> 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?
> That is,
>
> - For configurations we could report resource-ids that were
> added/deleted/changed or paths relative to the roots of the
> configurations.
> <jra>
> There could be multiple levels within the report. First differences in
> activities, then collections, then resources.
> </jra>
<jm>
Configuration comparison report using resource-ids:
<D:compare-response>
<D:changed>987344ab234d23d1581bc200876297ae</D:changed>
<D:changed>3876a876c76efb7ace34bf5f338efa24</D:changed>
<D:added>90823bd234ef23978df0ab2340c876eb</D:added>
<D:deleted>987b098867d0978e0978f098abe09848</D:deleted>
</D:compare-response>
Note: We could report the URI which gets us directly to the resources
indicated in the eample rather than just the resource-id. For example,
http:/foo.com/repo/resources/987344ab234d23d1581bc200876297ae
They are roughly equivalent.
Configuration comparison report using paths relative to roots (assume
base has roots A and B, and target has roots B and C where B refers to
the same resource in both cases):
<D:compare-response>
<D:added>C</D:added>
<D:added>C/fred.html</D:added>
<D:deleted>A</D:deleted>
<D:deleted>A/this.txt</D:deleted>
<D:deleted>A/x</D:deleted>
<D:deleted>A/x/that.gif</D:deleted>
<D:changed>B</D:changed>
<D:changed>B/e/g/h/foo.zip</D:changed>
<D:added>B/index.html</D:added>
</D:compare-response>
Note that this *requires* that all resources in a configuration be
reachable via some path starting at one of the roots. Otherwise we have
no way of talking about changes in a resource which is not reachable --
There is no path to put in the change element!! Note also that there may
be many paths to a given resource which was added, deleted or changed.
</jm>
> - For collections we report paths relative to the collections being
> compared.
> <jra>
> Sounds fine. What was added or deleted.
> </jra>
>
> - For activities, ????
> <jra>
> The differences between activities are what resources were
> changed in them.
> The
> merge conflict report would be a subset.
> </jra>
<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>
> - 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>
Jeff