office-collab — archive

Application requirement for Change Tracking: Document comparison

From: Patrick Durusau <[email protected]>
To: [email protected]
Date: Fri, 18 May 2012 00:01:00 -0000

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: [email protected] http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] -- Patrick Durusau [email protected] 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