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