Conceptualizing Change Marking
Michiel Leenaars
nenmail at staff.isoc.nl
Tue Jul 27 17:42:31 CEST 2010
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
More information about the sc34wg6
mailing list