Generic CT proposal - an implementer's look at it

[Thorsten Behrens <tbehrens@novell.com>]

Hi,

prompted by the recent activity around the two alternative change
tracking proposals, let me add the perspective of another
implementer (LibreOffice) to this discussion.

First off, I'd like to say that I find the generic proposal for
conditional modifications of xml elegant and concise - but I'm
afraid I cannot see a way to implement it, in a way that ensures
sufficient interoperability between different producers and
consumers.

Here's the crux: because the proposal relies solely on generic
modifications of the xml info set (both structurally, by changing
the tree, and by modifying attributes), and all those operations are
considered valid (section 3, items 6 and 7 of the
generic-ct-proposal), the set of semantically distinct editing
operations *is unbounded*.

Which is a fundamental problem, for all applications that need to
map the change tracking markup into their internal,
optimized-for-editing document models - because what you have here,
is a limited set of editing operations, that are closely related to
concrete user actions ("insert" an object, "delete" an object,
"merge" two objects - with a very application-specific meaning, that
may not map 1:1 to the xml representation).

Because of its genericity and expressive power, the generic ct
approach would be a very leaky abstraction over a producer's
internal representation - i.e. it would be very likely that
different applications produce different ct markup, for an otherwise
semantically identical user action - then in turn putting the onus
of interpreting that action correctly on the consuming application.

Cheers,

-- Thorsten

PGP signature