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