An ODF Implementor's View on Change Tracking

[Svante Schubert <Svante.Schubert@oracle.com>]

Hi,

I am new to the SC mailing list as an active member.
But instead of commenting right away on one of our current proposals, I would try to share some experience gained by working on collaboration for Oracle's Cloud Office.

Dependencies of Change-Tracking
The implementor of a new modern ODF office suite, which supports change-tracking, will recognize several office functionalities that work very closely together:

1. Versioning
   
2. Change tracking
   
3. Undo/redo
   
4. Collaboration with other users
   

There is a relationship between the items above. Roughly said: One item bundles multiple items listed directly below. More precisely:

1. One version contains several changes by one or more users
   
2. One change contains one or more undo/redo changes of one ODF component by a single user. Removing information undesired by the common user (e.g. it is irrelevant in what order the text of a paragraph has been added)
   NOTE: The ODF component is described in the presentation I mentioned earlier on the TC mailing list [1].
   
3. One undo/redo action might be a wired change event to other ODF clients
   (again there is usually a compression of information as text changed by undo/redo is in general not altered on character basis, but on larger granularity, e.g. words are undone/redone)
   

Potential Change-Tracking Requirement
From the above, our SC is currently focusing on serializing changes and postponed the run-time collaboration feature, as change-tracking is most important to our users. On the other hand when selecting the best change-tracking proposal we should as well have an eye on its interoperability with the upcoming collaboration feature otherwise we are loosing great potential for ODF applications:
For example, imagine full interoperability between change-tracking and collaboration. In this case it would be to map the change-tracking changes to a queue of collaboration events and vice versa. A user might than be able to apply document changes to other documents and save collaboration directly as standardized changes. The example above is a feature that can be taken as potential requirement for any change-tracking proposal.

Potential Change-Tracking Feature
The following example shows a potential change-tracking feature that is only enabled when doing a certain kind of collaboration.
Let me therefore take you a step further to common collaboration design to show you how collaboration features might influence the serialization of change-tracking.
User conflicts caused during collaboration are elegantly solved by the Operational Transformation (OT) approach [2] (OT is currently being used by Google's Web Office).
Some explaining words on Operational Transformation (OT). The OT approach maps the editing of a document to event calls. In OT theory even a complete document might be mapped to a queue of event calls, creating the document by events starting from scratch.
In OT the event is called operation and the transformation (the T from OT) occurs when an operation has to be adapted as a different operation happened earlier influencing it.
For example, there is a table operation to insert a column at position 3, but someone else has already inserted a column at position 2, the table operation therefore has to be transformed to insert the table at position 4 instead of 3, as the original document was changed earlier.

Now the nice side-effect: this transformation can not only be used for collaboration, but as well to move an operation (or a grouped set of operations) in the time-line of the queue.

Let me give a real-world example to show the potential:
Imagine you have to work on a version for the ODF specification.
Editing directly on the ODF specification, changing what is required from a task in our OASIS bug-tracker and grouping those changes to be related to this certain bug task.
When all changes for the version are completed, they are embraced to a new document version.
Now imagine the case where the deadline for the version arrives, but some issue is again under discussion. It was decided that the changes of that issue should not be part of that version, but still not be deleted as later still required. As the changes are only operations in a time-ordered queue they can be moved to the end of the queue, applying operational transformation when necessary. Moving the undesired change out of the version range.

To summarize:
Implementors do not care much about the implementation detail of the serialization of ODF change-tracking to ODF XML. But implementors do care very much to be able to map every single change to operations as used in collaboration to allow innovative ODF implementations.

Best regards,
Svante

[1] http://lists.oasis-open.org/archives/office/201107/msg00026.html
[2] http://www.waveprotocol.org/whitepapers/operational-transform

--

Svante Schubert | ODF Standardization
Phone: +49 40 23646 965
Oracle Office GBU

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle is committed to developing practices and products that help protect the environment