On Fri, 2012-07-20 at 18:31 -0600, André Rebentisch wrote:
> Am 20.07.2012 15:11, schrieb Patrick Durusau:
> > André,
> ...
> > To the best of my knowledge, intervening "untracked" changes have the
> > same result for all methods of change tracking.
> >
> > When there is a gap in the tracking of changes you have unpredictable
> > results.
>
> With change tracking info ignored by the consuming implementation, does
> the resulting saved XML document core reflect the state before (A) or
> after (B) changes were carried out? Obviously the former would result in
> difficulties when change tracking is not implemented by the consuming
> implementation. Thus you have to save state B and inversed change
> tracking (undo, "ODF history").
>
> Under MCT we have Svante's original concept with a notion of "inverse
> operations", undo.xml and .undo directory storage. The premise is that
> for each "add" operation you have an equivalent "remove" operation:
> "Every operation has an inverse operation"
>
> In a realtime multi-user collaboration environment (from which MCT too
> inspiration) you would rather want to follow a merge logic, based on a
> shared source document ("A") and sharing operations, and the analysis of
> the select committee largely followed a merge perspective in their
> examples (assumption that inversion was a simple technicality).
>
> How do the different approaches satisfy inversibility needs?
During the last year it was repeatedly stated that an ODF document with
change tracking information when read by a consumer that does not
understand the change tracking markup should appear as if all changes
had been accepted (your case B above). This seems to imply that the
document itself must always contain the final product.
Since all user actions are obviously reversible provided sufficient
information is kept I don't see how there is any huge difference between
recording an action or its inverse.
Andreas
--
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta
