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 Saturday 21 July 2012 06:06:04 Andreas J. Guelzow wrote:
> 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

I couldn't have said this better myself

Camilla


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