Conceptualizing Change Marking

[Dennis E. Hamilton]

Michiel,

My concern is that we are basing too much on missing information and limited
research.  I do not agree that the current specification is broken beyond
repair, although I am open to a demonstration of that.  

MY CONCERNS

I think the KOffice work-around was a mistake.  It wasn't understood that
deletions that break elements are actually handled properly in the major
implementation.  It is easy to demonstrate by doing the example where the
end of one list item and the beginning of the next list item are deleted.
The extracted fragment is adjusted in a systematic way so that it is
well-formed XML.  The adjustment is done such that if the deletion is
rejected, the fragment is restored back into the original XML properly.  At
no time is there any ill-formed XML.

It seems to me there was a misunderstanding based on the inadequacy of the
specification.  But one can see that the case is implemented in OO.o, one
can inspect the ODF to see what it looks like (without ever having to look
at implementation code), and it is demonstrable that there is proper
preservation of the change history when exporting to other formats and back
(e.g., to and from Microsoft Word .doc files).

A GREATER CONCERN

I would not want to see something that breaks this when all that is needed
is to repair the current description in the ODF specification.  I completely
agree that the description in the specification is awful.  I also notice
that people charged off inventing fixes without raising an issue with the
specification.  I am thankful that Ganesh Paramasivam provided us with a
valuable public comment in March of 2010.  That is now being handled as ODF
TC JIRA Issue OFFICE-2621,
<http://tools.oasis-open.org/issues/browse/OFFICE-2621>.  

I am no longer surprised that this sort of thing happens.  It seems to be
the rule, not the exception.  But private workarounds without seeking out an
open, public clarification compounds the problem and I'm not sure I should
be terribly sympathetic.

LOOKING AHEAD

With regard to places in ODF where change-tracking is unavailable and is
important to have, I have no objection.  I just don't want us to fix the
wrong thing where change-tracking is already observably working and it is
the specification that cries out to be debugged.

I too await the details of the new proposal, and I value that there has been
much research into having a well-specified version.

 - Dennis

-----Original Message-----
From: Michiel Leenaars [mailto:nenmail at staff.isoc.nl] 
Sent: Tuesday, July 27, 2010 08:43
To: dennis.hamilton at acm.org
Cc: SC 34 WG 6 mailing list
Subject: Re: Conceptualizing Change Marking

[ ... ]

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. 

[ ... ]