An Abiword / Calligra developer's view of the Change Trackingevents.

[monkeyiq <monkeyiq@gmail.com>]

Hi,
  As I have been a non vocal member of the list, many folks will likely
not know me. I have hacked on KOffice/Calligra and Abiword. For the
latter I have made a reasonable headway toward implementing the original
"generic" change tracking proposal for ODF. I am not particularly
affiliated with any company. This includes DeltaXML who proposed the
"generic" change tracking and Microsoft who proposed the "extended"
change tracking. 

  I am more in favour of discussing things on the mailing list than
conference calls. My timezone tends to make the conference calls harder
to make.

  At the very least I should highlight to the group that there is a git
branch of Abiword publicly available on github which supports the
"generic" change tracking proposal for paragraph split/merge, text
addition/deletion, move paragraph, toggle heading style, and growing
support for the delta:merge swiss army knife. This will be folded into
an upcoming mainstream release of abiword.

  So there are two existing implementations of the "generic" proposal;
abiword and the work of Ganesh Paramasivam on KWord/Calligra. The timing
of the "extended" proposal seems a little odd to me, as it was mentioned
last year in Brussels that projects were looking to implement the
generic proposal for ODF change tracking. In the interests of friendly
collaboration I would have hoped that alternatives would have been
tabled at that time or shortly thereafter. In light of the now existing
implementations of the generic proposal, my vote would be to use the
generic proposal and cherry pick things from the "extended" proposal as
needed.

  How closely does the "extended" proposal mirror what is performed by
Microsoft Word for non ODF formats? For me, it would be interesting to
see how these things play out, and how the user interface offers such
functionality in an existing implementation of the "extended" proposal.
Even if that implementation stores in non ODF currently.

  Over the last few days I have been bringing myself up to speed on the
"extended" proposal. I think perhaps many citations in the extended
proposal are to older change tracking rather than the "generic" one. As
an example, the move content on page 4/19 of the extended proposal
mentions that move is currently handled as delete/insert and no link
between the two. Clearly in the generic proposal such a link is explicit
as mentioned on page 17/23 of the generic proposal.

  The moving of multiple non-contiguous blocks of text as mentioned in
the "extended" proposal is quite interesting. Perhaps a more fluid
example would be moving a paragraph with D&D and then deciding that
other content should subsequently be moved too as part of a single
semantic "reorganize" operation. IMHO it would be rare to expect the
user to control-select many non contiguous blocks and decide to move
them at once.

  The question then becomes does a delta:change-transaction provide fine
enough granularity to capture these cases, or should we also have
something at a sub revision level, like text:changed-region, to allow
markup of these grouped moves. Or alternately, should some RDF be able
to reference each delta:insertion-change-idref to allow such relations
and others to be captured explicitly.

  It seems to me having sub revision level constructs also runs the risk
of being forgotten by the user. For example, I might move a paragraph
and then decide to move a non-contiguous one but would really like to
emphasise that these moves are very strongly related. And what if I
fixed a spelling mistake after the first move but before the second?

  One thing which might be useful at a sub revision level would be
time_t values (relative to UTC 1970 or as ISO 8601/dc:date encoding).
This way a second paragraph move would also explicitly let the viewer
know that it was moved on the same day 12 minutes after the last
paragraph move. And 7 minutes after the text "great stuff" was added.

  I'll split out subsequent comment on the extended proposal to another
email as this is getting long already.