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 20:43 -0600, André Rebentisch wrote:
> Am 21.07.2012 03:17, schrieb Andreas J. Guelzow:
> >> 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. 
> 
> Indeed, so my observation was we are actually not dealing with Merge-CT
> but Undo-CT, its inversed twin.
> 
> > 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.
> 
> Trivial example:
> A: "Rock Scissors Paper"
>  op1: apply "bold face" to Rock
>  op2: apply "bold face" to Paper
>  op3: apply "bold face" to whole string
> OR
>  op2: apply "bold face" to S
>  op3: apply "bold face" to Scissors
> 
> How to undo op3? In the world of "merge" collaboration the task is very
> convenient and smooth: Take saved state A and apply op1,op2. In a
> "merge" view complex "user centric changes" (Patrick) are no issue
> because you can reproduce them one by one based on the source A.
> 
> With a need for inversed operations you have to translate a "user
> centric" op3 into what it actually changes and implement "real undo".
> Implementation of inversion for more complex editing operations may
> become a bit messy. You may end up with XML diffs even under MCT
> (replace X by Y operations).

I would think that every editing application already implements
undo/redo, so all this "messiness" is already handled within that
application. On load or save one would only translate that into
appropriate markup.

Using some like GCT on the other hand, during save one would need to
figure out how the xml changes through the editing op and then encode
the xml changes. For applications whose internal data structures don't
match ODf this would be significant work. And on load this would even be
more difficult.

Andreas
-- 
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]