Conceptualizing Change Marking

[Michiel Leenaars]

Hi Dennis,

thanks for the link. I'll have a detailed look at it (I am currently at the IETF, where 
we just launched a grant programme for work on an important new internet 
security standard called DNSSEC). Looks interesting, especially for blind
users of Office products (where visual metaphors fail).
 
> So there are two problems, as I see it.  First, the ODF specifications need
> to be repaired so that the specified places where change history is supposed
> to work already are supported by correct specifications.  The second matter,
> which we should keep separate, is any addition of further change-tracking
> features for cases that the repaired ODF specification does not handle.

I would agree that technically these are different problems, yet if the second 
problem is solved by the only solution to the first problem it is reduced back to 
one problem. I would argue that this is the case.

The current specification of track changes in ODF 1.0 is defect in that applications
can't rely on it for interoperability; the fact that various applications have 
each extended the specified behaviour with additional mechanisms to track 
a small subset of change types with limited success illustrates that. KOffice
is able to deal with mixed type changes (deletion of text spanning part of 
a list and text paragraphs for instance) using ODF RDF metadata, which many 
other applications cannot deal with (but which works for KOffice users among
each other). OpenOffice.org does something different, and so does AbiWord etc.
There is no reasonable choice to make among these different mechanisms 
that would not discriminate others, so as I see it there is nothing to describe
that 'works'.  The fact is that the conceptual model itself is incomplete which 
resulted in different non-interoperable extensions deployed out there 
- making the current specification technically broken beyond repair. 

After careful research we did not see any way to unite the various features 
from different applications within the model in an interoperable way - making 
a new model inevitable for repair. The new model does not suffer any of these 
complications, and will work for all applications. It provides a generic and 
robust mechanism that captures all use cases from all applications we were 
aware of - including spreadsheets and presentations for that matter. I would 
love to hear if there are any ODF applications out there that have any change 
they cannot track with this new part of the specification. I cannot imagine any 
repaired version of the current model for all versions of ODF that would deal 
with all use cases. By moving to another mechanism we get all the extra 
functionality for free with the repair, which is an extremely nice bonus. 

Of course for interoperability with legacy applications the deprecated legacy 
application defined behaviour and formatting may be used (and could be 
described by each of the vendors), but for the ODF standard the most 
obvious thing to do is not to go into a lot of controversy for adopt a 
non-broken mechanism into the standard - and just deprecate the
old broken one in favor of a working one as soon as possible.

Best,
Michiel Leenaars
Director of Strategy
NLnet foundation

VP OpenDoc Society