Application requirement for Change Tracking: Document comparison

Robin,
More tomorrow but for tonight:
OK, when you say text or table you mean anywhere in the ODF format
where PCDATA can occur and/or any changes to the structure of a
table for a *text* document, those changes must be capable of
acceptance/rejection.
May I assume that the maker of the changes is always logged? No
anonymous changes?
Along with the date of changes?
Interesting requirement concerning changes to auto-generated indexes
(TOC is a type of index) and list numbering.
Other auto-generated materials? page numbers? footnotes? caption
numbering?
BTW, I assume that where there is original document A, to which
changes are made, resulting in document B, and document A is also
changed by another user to make document C, that your client would
recognize there can be some conflicting changes where cannot be
automatically merged.
Both B and C start from the same original but make inconsistent
changes to their copy of the original.
Hope you are having a great day!
Patrick
On 05/17/2012 05:28 AM, Robin LaFontaine wrote:
In preparation for Monday's call, here is a brief
statement of requirements for our customers who need, for very
good reasons, to know the differences between two documents and
also to merge changes made to copies of one document.
Our application using ODF is in comparing documents,
specifically ODT. The customer that originally sponsored this
work was submitting large legal/financial documents to
regulators and they required that  every  change to any
text or table was shown in the result. (They did not require
changes to format to be shown though we have had requests from
others for this. But they did want to see changes to generated
information such as table of content and list item numbers.)
As ODT 1.1 track change format was so limited, we had to do this
using text decoration which had the limitation that changes
could not be accepted/rejected, only viewed. Viewing the changes
was, however, their main requirement for submission to
regulators, so we managed to provide a solution for them despite
limitations in ODT 1.1.
We were also asked to write a merge tool so that multiple
lawyers could change different copies of the document at the
same time and then the changes are merged together. Again, we
were  very  limited due to the capabilities of the change
tracking format in ODT 1.1. For this application to work
properly,  every  change that an editor can make needs to
be represented, i.e. any change to the document. This is
essentially a non-real-time (batch) collaboration requirement.
The importance of change tracking here is to enable
accept/reject changes and to allow conflicting changes to be
handled.
If ODT is to be useful for legal and legislative documents then
it needs to be capable of tracking even minor changes - lawyers
and regulators are very particular, for good reason.
Note: Due in part to the limitations of ODT 1.1 change tracking,
our customer was forced to move away from ODF. If the change
tracking had been better, the story might have been different.
Robin
--  --

-----------------------------------------------------------------

Robin La Fontaine, Director, DeltaXML Ltd
Experts in information change  T: +44 1684 592 144  E:  
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

---------------------------------------------------------------------

To
unsubscribe, e-mail:

For additional commands, e-mail:


--
Patrick Durusau  
Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps)

Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

OASIS Technical Advisory Board (TAB) - member  Another Word For It (blog):  http://tm.durusau.net  Homepage:  http://www.durusau.net  Twitter: patrickDurusau