Suggestions for moving forward to resolve issues

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

At the last call, Rob said that he would discuss the next steps with myself, as chairman of this group, and Michael, as co-chairman of the TC.

We have had some discussions and, as Rob says, our view is that it is not helpful to go for a vote at this point, either in this subcommittee or in the TC. As we continue to discuss the issues, we seem to be gaining a better understanding of why there is  a divergences of views. Only by understanding the reasons behind this can we have any hope of coming up with a good solution.

There is clearly merit in both of the proposals that have been made. Therefore ideally we would like to combine the best aspects of both in a solution.

We have identified two main areas where views seem to be divergent:

1. Implementation: is the GCT impossible/difficult/expensive to implement?

2. Scope: should all changes be tracked or only those that editing applications currently track?

These are explored further below.

The best aspects of each proposal seem to be (ignoring for now any downsides):
GCT: generic solution covers any change, now and in future
ECT: based on the semantic CT requirements of editing applications

If we can combine these best aspects then we could have a solution that will have broad support. We believe it is worth some time and effort to see if this can be done.

Suggested Actions

A1. To resolve the issue over implementation, please could those who currently feel that the GCT is impossible/difficult/expensive to implement talk to those who have already done implementations? Perhaps the question to answer is: what restrictions could be put in place to make it easier to implement the GCT?

A2. To see if we can combine the best aspects or the two proposals, please would anyone who has ideas on this propose them for discussion.

A3. Conference call, again perhaps chaired by Rob, possibly on Tues 17 May (not yet checked with Rob) at the usual time to check if we are converging on a solution.

Note: Regarding scope, I am not sure a discussion here is useful - both views seem to be valid and so would need to be supported in any solution. But, I would not want to prevent any further discussion!


DETAILED NOTES ON ISSUES

1. Implementation: is the GCT impossible/difficult/expensive to implement?

Rob describes the implementation issue as something like this:

"Change tracking is recorded and accepted or rejected in the runtime of the  editor.  At this point, the original ODF document has been read into memory structures that are optimized for that editor's runtime, but which bear no direct 1-to-1 correspondence with the ODF markup model.  Although each application will need to be able to load and save documents consistently in ODF, at runtime they are dealing with an entirely different abstraction.  This makes it tricky to process change tracking that is described as operations on the markup.  The ability to translate an entire document in memory to ODF at save time does not mean that apps can easily process an XML diff at runtime, after the document has already been loaded."

However, we now have both Koffice and Abiword implementations (not full, but quite a significant proportion), not to mention WebODF viewer. Indeed, we have full reports submitted to the subcommittee on the implementation work and the issues they found. So, this seems to demonstrate that implementation could be more of a perceived problem than a real one.

Clearly change tracking is a big challenge, and implementing it is never going to be easy. The question is whether it is that much harder in the generic format than the extended one. Given the above implementations, and given the fact that OpenOffice and LibreOffice are probably closer to ODF, is it really an impossible problem? Can someone articulate why it is difficult, and how it could be easier?


2. Scope: should all changes be tracked or only those that editing applications currently track?

There seem to be two viewpoints:

V1. Editor Feature viewpoint: CT should support the features in editors, no more and no less. Therefore editor application programmers need to agree on what these are and then they can be implemented in ODF.

V2. Document Version viewpoint: CT should support changes to the ODF representation of a document, so it should be possible to roll-back to any previous version. It should be possible to track any change even if a particular application cannot handle the change.

View V1 does not want a view V2 solution because it is impossible to implement fully. View V2 regards V1 solution as inadequate for other applications and a moving target: as editors have new features the standard will need to be changed.

Since by definition V2 must include all of V1, a solution that allows V2 but can be constrained to V1 could be a possible way forward.

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK