Conceptualizing Change Marking

robert_weir at robert_weir at
Tue Jul 27 23:05:37 CEST 2010

Hi Michiel,

I'm supportive of any attempt to improve ODF in this area.  So you have my 
thanks for your efforts in putting together this proposal.

When you are ready to make a specific technical proposal, could you send 
it to the OASIS ODF TC's public comment list as well? 



sc34wg6-bounces at wrote on 07/27/2010 11:42:31 AM:

> 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 
> users of Office products (where visual metaphors fail).
> > So there are two problems, as I see it.  First, the ODF specifications 
> > to be repaired so that the specified places where change history is 
> > to work already are supported by correct specifications.  The second 
> > which we should keep separate, is any addition of further 
> > features for cases that the repaired ODF specification does not 
> 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 
> a small subset of change types with limited success illustrates that. 
> is able to deal with mixed type changes (deletion of text spanning part 
> a list and text paragraphs for instance) using ODF RDF metadata, which 
> other applications cannot deal with (but which works for KOffice users 
> each other). 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 
> from different applications within the model in an interoperable way- 
> a new model inevitable for repair. The new model does not suffer anyof 
> complications, and will work for all applications. It provides a generic 
> robust mechanism that captures all use cases from all applications we 
> aware of - including spreadsheets and presentations for that matter. I 
> love to hear if there are any ODF applications out there that have any 
> 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 
> 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 
> Of course for interoperability with legacy applications the deprecated 
> 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
> _______________________________________________
> sc34wg6 mailing list
> sc34wg6 at

More information about the sc34wg6 mailing list