RE: compare-baseline report with subbaselines

Good point.  We did neglect to define the DAV:compare-baseline
behavior on subbaselines.  We could:

- Have subbaselines appear in DAV:added-version, DAV:deleted-version,
and DAV:changed-version elements.  This is reasonable, since a baseline
is a special kind of version

- Have DAV:compare-baseline "recurse" into subbaselines, and report on the
versions of those subbaselines.

I probably prefer the former behavior, since otherwise the behavior of
adding a
subbaseline or deleting a subbaseline gratuitously inflates the size of
the report.

A variant of the second approach would be to just report added and deleted
baselines in added-version and deleted-version elements, but to
automatically 
recurse into baselines that appear in DAV:changed-version elements.

A variant of this variant would be to have this "recurse" behavior
controlled
by an explicit parameter to DAV:compare-baseline.

But I'd probably still go for the simple version of the second behavior
(i.e. never
recurse), since a client could always recurse itself, if it wanted to.

This probably counts as "clarifying an ambiguity", 
rather than "adding or changing behavior", so
an argument could be made to add this wording during the final edit pass.
Would anyone object to this?

Cheers,
Geoff

-----Original Message-----
From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]
Sent: Sunday, January 27, 2002 5:12 PM
To: ietf-dav-versioning@w3.org
Cc: Edgar@EdgarSchwarz.de
Subject: compare-baseline report with subbaselines


Hi,
in 12.7.1 there is a nice example of a compare-baseline report.
But how does it look with subbaselines ?
Added or deleted subbaselines won't be a problem.
But how do we describe changed subbaselines ? Here some recursion
seems to be necessary (Depth infinity).
Another remark (not wanting to change that in the current draft):
In 12.12 (one-version-per-history-per-baseline) we extend this
to the subbaselines. I remember this restriction coming from merging
problems.
I feel this isn't necessary if merging has a configuration scope (excluding
subconfigurations). 

Cheers, Edgar




-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Active Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Monday, 28 January 2002 14:13:08 UTC