OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Inversed MCT

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 J. Guelzow, PhD, FTICA
Concordia University College of Alberta

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]