Comments on Change Tracking Proposals

[Svante Schubert <svante.schubert@gmail.com>]

Hi Robin,

I have read your change tracking analysis with interest, especially I like your idea of using a SWOT analysis.
Not like John and Thorsten, I will respond without editing the original document, but providing a personal view.

SC Requirement

The current mission objective of our SC in one sentence, would come down to:
"Find the optimal way of serializing/saving run-time changes of ODF applications"
Aside of the above prioritized objective, we have collaboration as part of our goals in our charter and of course interoperability of ODF applications as overall goal and reason for writing the ODF specification.

SC Status

The finding of the optimum solution for CT is ongoing. All have advantages (unlike you, I am also considering designs without formal proposal)

• GCT aims to win the price for the most generic and smallest specification change and additional interoperability with other XML formats. ODF applications using ODF XML DOM during run-time have an advantage.
  
• ECT aims to win the price for the smallest code-change for applications implementing ODF 1.0 / 1.1 change-tracking

Now I would like to add one new half-fictional proposal, which is interesting as rumor says there is some EU funding involved and the result might come back to us sooner or later:

• GIT is being used to track all the changes within the zip, by adding a .git directory. This concept works for source code revision control.
  This approach aims to win the price for the best coverage of changes within the package.

And finally what was only drafted, but yet not formally proposed

• CCT aims to win the price for interoperability with change tracking.

Discussion of different Approaches

I would like to assume that every approach is able to cover change tracking in general.
Instead the focus will be on interoperability. Interoperability is the reason for the TC's existence. Our first requirement is to establish interoperability between ODF applications.

An ODF application that would like to support ODF change-tracking should be able get all necessary informations about the minimum required set to cover change-tracking with other ODF applications.
Similar to ODF OpenFormula there might be multiple different sets in the end. At least there has to be an initial minimum set to guarantee full interoperability with other CT supporting ODF applications.
This change set will define automatically the mandatory part (of a mime type) already required by the ODF TC charter: "establishing a set of 'core' elements and attributes to be supported by all implementations"
Do we have common agreement that we need to establish this first mandatory set here at the SC?

If we have agreement, this criteria is instantly a k.o. criteria for the GIT approach, as it is not fine granular enough to allow the creation of ODF changes.
In addition it mandates the remaining approaches to identify supported ODF changes, e.g. "moveColumn".

GCT eases the implementation for run-time XML based ODF applications and gives in its original form little impact on the specification as its neglects the semantic of ODF changes.
But as none XML run-time ODF applications such as Libre/OpenOffice need to know what XML changes would have to be implemented first, GCT have to define this set (but ECT and CCT as well).

Now there is a different requirement on the roadmap of this SC - collaboration.
Although the SC agreed on the priority in implementing CT, collaboration will be the next on our list.

Allow me to give one exemplary user scenario of ODF collaboration. Two ODF applications would like to collaborate in real-time. One is a browser with special _javascript_ support, one is an ancient Office (e.g. Libre/OOo).
Both ODF applications are able to save their run-time states to identically ODF documents, although one is using an internal HTML/CSS model, the other a ODF related C++ model.
As the real-time changes should be fine granular and fast similar to Google Docs, we need make the changes fine granular and efficient. Change-events based on a common model comes first to mind (see CCT).
Sending ODF GIT patches to the browser, or ODF XML changes made from GIT or ECT will be painful to map to the HTML/CSS core via _javascript_. Instead similar components in each application (e.g. table) have ways to exchange state, e.g. moveColumn.
It seems there are several design solutions possible for CT, but only one design works well for collaboration.

Now it should be noted, that there is a direct relation-ship between CT and collaboration.
The difference between serializing change tracking and collaboration change-events is only the aggregation level.
While change tracking only saves the differences between the start and end of the session, collaboration change-events still embraces any intermediate changes.
It is therefore possible to map one to the other.

It comes down to the following question:
Which commercial project would choose a design for its first week, when it does not fit next week's requirement?
We might of course add a second redundant implementation for the similar functionality (CT/collab), but more efficient implementations and more interoperability between CT and collab will provide us only the CCT approach.
To me this a k.o. to GCT and ECT.

The next step would be to find the first change tracking milestone to be implemented by all ODF applications.
Office user require interoperability with all office documents, therefore we should aim for interoperability with OOXML CT, therefore the ECT scenarios from Microsoft seem to be a good starting point.

Regards,
Svante