OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings! Apologies for the slow posting! The only additional requirement uncovered by the select committee is: Nested change tracking, which the committee takes to mean, with change tracking on: 1st case: 1st author creates a text, saves it and transfers it to 2nd Author. The 2nd author makes changes. The 2nd author transfers the text back to the original author. The 1st author makes changes to the changes made by the 2nd author. 2nd case: Author creates a text and saves it (not auto-save). After manual save, author makes changes to the text. After another manual save, the author makes changes to their changes. (The manual save was suggested as a session marker for engagement of change tracking.) Advocates of change tracking proposals should post (email is fine) examples of how their proposals handle nested change tracking as illustrated by these two cases. Hope everyone is having a great week! Patrick -- Patrick Durusau patrick@durusau.net Former 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) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

Patrick, Thanks for these examples - I think it would help if we all encoded exactly the same sample, so here is my suggestion (which is subject to your approval that I have interpreted your cases correctly) 1st Case 1. Original saved by 1st author <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 2nd author changes text: <text:p>This is the second version of the paragraph , created with change tracking on so seen as a modifed paragraph. </text:p> Transferred back to 1st author, but that is not a further change. 2nd case 1. Original <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 1st author changes text: <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph, which is then modified.</text:p> 3. 1st author changes text again: <text:p>This is the modified paragraph, created with change tracking on so seen as an added paragraph, which is further modified.</text:p> Are these specific examples OK? Robin On 14/06/2012 00:19, Patrick Durusau wrote: Greetings! Apologies for the slow posting! The only additional requirement uncovered by the select committee is: Nested change tracking, which the committee takes to mean, with change tracking on: 1st case: 1st author creates a text, saves it and transfers it to 2nd Author. The 2nd author makes changes. The 2nd author transfers the text back to the original author. The 1st author makes changes to the changes made by the 2nd author. 2nd case: Author creates a text and saves it (not auto-save). After manual save, author makes changes to the text. After another manual save, the author makes changes to their changes. (The manual save was suggested as a session marker for engagement of change tracking.) Advocates of change tracking proposals should post (email is fine) examples of how their proposals handle nested change tracking as illustrated by these two cases. Hope everyone is having a great week! Patrick -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On Monday 18 June 2012 16:44:52 Robin LaFontaine wrote: > Patrick, > > Thanks for these examples - I think it would help if we all encoded > exactly the same sample, so here is my suggestion (which is subject to > your approval that I have interpreted your cases correctly) > > 1st Case > > 1. Original saved by 1st author > <text:p>This is the original paragraph, created with change tracking on so > seen as an added paragraph.</text:p> > > 2. 2nd author changes text: > <text:p>This is the second version of the paragraph, created with change > tracking on so seen as a modifed paragraph.</text:p> > > Transferred back to 1st author, but that is not a further change. > > 2nd case > > 1. Original > <text:p>This is the original paragraph, created with change tracking on so > seen as an added paragraph.</text:p> > > 2. 1st author changes text: > <text:p>This is the original paragraph, created with change tracking on so > seen as an added paragraph, which is then modified.</text:p> > > 3. 1st author changes text again: > <text:p>This is the modified paragraph, created with change tracking on so > seen as an added paragraph, which is further modified.</text:p> > > Are these specific examples OK? > > Robin Hi Yes this would serve as a good example where we can easily compare the various encodings of change tracking

Robin, Apologies for the slow response! Comments below: On 06/18/2012 10:44 AM, Robin LaFontaine wrote: Patrick, Thanks for these examples - I think it would help if we all encoded exactly the same sample, so here is my suggestion (which is subject to your approval that I have interpreted your cases correctly) 1st Case 1. Original saved by 1st author <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 2nd author changes text: <text:p>This is the second version of the paragraph , created with change tracking on so seen as a modifed paragraph. </text:p> Transferred back to 1st author, but that is not a further change. 2nd case 1. Original <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 1st author changes text: <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph, which is then modified.</text:p> 3. 1st author changes text again: <text:p>This is the modified paragraph, created with change tracking on so seen as an added paragraph, which is further modified.</text:p> Are these specific examples OK? Yes, with the understanding that the second example should reflect a manual save event that fixes the text that is then subject to change tracked modification. In other words, if in a single editing session, with no saves, I type: Here is the incorrect text. and seeing I have made a mistake I move the cursor and reform the text to read: Here is the correct text. There should be no change tracking recorded because I am in a single editing session. Or did I succeed in making the use case less clear? Thanks! Hope you are having a great day! Patrick Robin On 14/06/2012 00:19, Patrick Durusau wrote: Greetings! Apologies for the slow posting! The only additional requirement uncovered by the select committee is: Nested change tracking, which the committee takes to mean, with change tracking on: 1st case: 1st author creates a text, saves it and transfers it to 2nd Author. The 2nd author makes changes. The 2nd author transfers the text back to the original author. The 1st author makes changes to the changes made by the 2nd author. 2nd case: Author creates a text and saves it (not auto-save). After manual save, author makes changes to the text. After another manual save, the author makes changes to their changes. (The manual save was suggested as a session marker for engagement of change tracking.) Advocates of change tracking proposals should post (email is fine) examples of how their proposals handle nested change tracking as illustrated by these two cases. Hope everyone is having a great week! Patrick -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- Patrick Durusau patrick@durusau.net Former 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) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

Patrick - thanks for your clarification, I did interpret it correctly and will post a GCT solution in a following email Robin On 21/06/2012 11:48, Patrick Durusau wrote: Robin, Apologies for the slow response! Comments below: On 06/18/2012 10:44 AM, Robin LaFontaine wrote: Patrick, Thanks for these examples - I think it would help if we all encoded exactly the same sample, so here is my suggestion (which is subject to your approval that I have interpreted your cases correctly) 1st Case 1. Original saved by 1st author <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 2nd author changes text: <text:p>This is the second version of the paragraph , created with change tracking on so seen as a modifed paragraph. </text:p> Transferred back to 1st author, but that is not a further change. 2nd case 1. Original <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 1st author changes text: <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph, which is then modified.</text:p> 3. 1st author changes text again: <text:p>This is the modified paragraph, created with change tracking on so seen as an added paragraph, which is further modified.</text:p> Are these specific examples OK? Yes, with the understanding that the second example should reflect a manual save event that fixes the text that is then subject to change tracked modification. In other words, if in a single editing session, with no saves, I type: Here is the incorrect text. and seeing I have made a mistake I move the cursor and reform the text to read: Here is the correct text. There should be no change tracking recorded because I am in a single editing session. Or did I succeed in making the use case less clear? Thanks! Hope you are having a great day! Patrick ..snip -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

Here are GCT representations of the two cases that Patrick proposed. Mainly hand crafted so there may be errors but I believe it is ok. Notes 1. The delta:tracked-changes element is just a wrapper for the meta info about each edit, e.g. author, time etc. 2. In general, edits could only be undone in the reverse order 3. Deleted text is in situ but could easily be moved into another location and replaced with a marker (this would be intended for ODF to comply with existing features) CASE 1 1. Original saved by 1st author <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 2nd author changes text: <text:p>This is the second version of the paragraph , created with change tracking on so seen as a modifed paragraph. </text:p> Transferred back to 1st author, but that is not a further change. <delta:tracked-change-demo xmlns:ac= http://www.deltaxml.com/ns/track-changes/attribute-change-namespace xmlns:dc= http://purl.org/dc/elements/1.1/ xmlns:delta= http://www.deltaxml.com/ns/track-changes/delta-namespace     xmlns:text= urn:oasis:names:tc:opendocument:xmlns:text:1.0     xmlns:office= urn:oasis:names:tc:opendocument:xmlns:office:1.0 >     <office:text >         <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= p3_d22e1 >This is the             <delta:removed-content delta:removal-change-idref= p3_d22e6 >original </delta:removed-content>             <delta:inserted-text-start delta:insertion-change-idref= p3_d22e6 delta:inserted-text-end-idref= i3_d22e9 />             second version of the             <delta:inserted-text-end delta:inserted-text-end-id= i3_d22e9 />             paragraph, created with change tracking on so seen as             <delta:removed-content delta:removal-change-idref= p3_d22e12 >an added</delta:removed-content>             <delta:inserted-text-start delta:insertion-change-idref= p3_d22e12 delta:inserted-text-end-idref= i3_d22e15 />             a modifed             <delta:inserted-text-end delta:inserted-text-end-id= i3_d22e15 />             paragraph.</text:p>     </office:text>      <delta:tracked-changes>         <delta:change-transaction delta:change-id= p3_d22e1 >             <delta:change-info>                 <dc:creator> 1st author </dc:creator>                 <dc:date>20120618T145703+0100</dc:date>             </delta:change-info>         </delta:change-transaction>         <delta:change-transaction delta:change-id= p3_d22e12 >             <delta:change-info>                 <dc:creator> 2nd author </dc:creator>                 <dc:date>20120618T145922+0100</dc:date>             </delta:change-info>         </delta:change-transaction>         <delta:change-transaction delta:change-id= p3_d22e6 >             <delta:change-info>                 <dc:creator>2nd author</dc:creator>                 <dc:date>20120618T145922+0100</dc:date>             </delta:change-info>         </delta:change-transaction>     </delta:tracked-changes> </delta:tracked-change-demo> CASE 2 1. Original <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 1st author changes text: <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph, which is then modified.</text:p> 3. 1st author changes text again: <text:p>This is the modified paragraph, created with change tracking on so seen as an added paragraph, which is further modified.</text:p> <delta:tracked-change-demo xmlns:ac= http://www.deltaxml.com/ns/track-changes/attribute-change-namespace xmlns:dc= http://purl.org/dc/elements/1.1/ xmlns:delta= http://www.deltaxml.com/ns/track-changes/delta-namespace     xmlns:text= urn:oasis:names:tc:opendocument:xmlns:text:1.0     xmlns:office= urn:oasis:names:tc:opendocument:xmlns:office:1.0 >      <office:text >         <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= p3_d22e1 >This is the <delta:removed-content delta:removal-change-idref= p3_d22e6 >original</delta:removed-content>             <delta:inserted-text-start delta:insertion-change-idref= p3_d22e6 delta:inserted-text-end-idref= i3_d22e9 />             modified             <delta:inserted-text-end delta:inserted-text-end-id= i3_d22e9 />             paragraph, created with change tracking on so seen as an added paragraph             <delta:inserted-text-start delta:insertion-change-idref= p3_d22e7 delta:inserted-text-end-idref= i3_d22e7 />             , which is <delta:removed-content delta:removal-change-idref= p3_d22e12 >then</delta:removed-content>             <delta:inserted-text-start delta:insertion-change-idref= p3_d22e12 delta:inserted-text-end-idref= i3_d22e15 />             further             <delta:inserted-text-end delta:inserted-text-end-id= i3_d22e15 />             modified             <delta:inserted-text-end delta:inserted-text-end-id= i3_d22e7 />             .</text:p>     </office:text>     <delta:tracked-changes>         <delta:change-transaction delta:change-id= p3_d22e1 >             <delta:change-info>                 <dc:creator>1st author</dc:creator>                 <dc:date>20120618T145922+0100</dc:date>             </delta:change-info>         </delta:change-transaction>         <delta:change-transaction delta:change-id= p3_d22e7 >             <delta:change-info>                 <dc:creator> 1st author </dc:creator>                 <dc:date>20120618T151005+0100</dc:date>             </delta:change-info>         </delta:change-transaction>         <delta:change-transaction delta:change-id= p3_d22e6 >             <delta:change-info>                 <dc:creator> 1st author </dc:creator>                 <dc:date>20120618T151113+0100</dc:date>             </delta:change-info>         </delta:change-transaction>         <delta:change-transaction delta:change-id= p3_d22e12 >             <delta:change-info>                 <dc:creator> 1st author </dc:creator>                 <dc:date>20120618T151114+0100</dc:date>             </delta:change-info>         </delta:change-transaction>        </delta:tracked-changes> </delta:tracked-change-demo> -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

Here the MCT representations of the two cases that Patrick proposed. Please excuse the delay, I had been working on an MCT prototype based on the Apache (Incubating) ODF Toolkit and had been distracted from this task. CASE 1 1. Original saved by 1st author < text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 2nd author changes text: <text:p>This is the second version of the paragraph , created with change tracking on so seen as a modifed paragraph. </text:p> <text:p>This is the original paragraph , created with change tracking on so seen as a paragraph. </text:p> // FILEPATH ./content.xml // DESCRIPTION:  The following is part of a content.xml file, similar abbreviated as Robin did before <xmlns:text= urn:oasis:names:tc:opendocument:xmlns:text:1.0 xmlns:office= urn:oasis:names:tc:opendocument:xmlns:office:1.0 >     <!-- ... -->     <office:text >         <text:p>This is the second version of the paragraph , created with change tracking on so seen as a modifed paragraph. </text:p>     </office:text>     <!-- ... --> // FILEPATH ./meta.xml // DESCRIPTION:  Store all metadata of changes in the metadata file. <office:document-meta office:version= 1.3     xmlns:meta= urn:oasis:names:tc:opendocument:xmlns:meta:1.0     xmlns:office= urn:oasis:names:tc:opendocument:xmlns:office:1.0     xmlns:dc= http://purl.org/dc/elements/1.1/ >     <office:meta>         <meta:generator>ODFApp/1.0$Win32/123m1$Build-007</meta:generator>         <meta:creation-date> 20120618T145700+0100 </meta:creation-date>         <meta:initial-creator xml:id= User1 > 1st author </ meta:initial-creator >         <dc:creator xml:id= User2 >2nd author </dc:creator>         <dc:date> 20120618T145922+0100 </dc:date><!-- time of change the ODF XML is related to -->         <dc:language>en-US</dc:language>         <meta:editing-cycles>2</meta:editing-cycles>     <office:meta> </office:document-meta>   // FILEPATH ./changes/undo.xml // DESCRIPTION:  Undo change operations are being stored in this file. The directory is useful for keeping changed binary data < undo xmlns= http://docs.oasis-open.org/ns/office/1.3/merge/ct# meta-file= ../meta.xml >     <add type= text time= 23s         by = User1 s= /1/1 > This is the original paragraph, created with change tracking on so seen as an added paragraph.</add>     <del type= text time= 1m58s   by= User2 s= /1/12 e= /1/20 />     <add type= text time= 2m01s   by= User2 s= /1/12 > second version of the </add>     <del type= text time= 2m17s   by= User2 s= /1/89 e= /1/96 />     <add type= text time= 2m22s   by= User2 s= /1/89 >modified</add> </ undo > The creation time is of the time, when the empty document is being loaded. All following editing operations are relative to this origin time. The various users/editors are written in the meta.xml and referenced by the undo.xml file. The start and end parameter of each operation is relative to state of the content.xml just before the operations occurs. The problem of (real-time) collaboration is similar to the problem of the shell game (or thimblerig). In a shell game you have one marble under several shells and you have to take track of the shell with the marble. In collaboration others are changing the content and someone has to take track of the own changes. This magic of the solution is enabled by operations and their relative references, but is happening during run-time and is hidden from the specification. It is called Operational Transformation (OT) [1][2][3]. Basically OT is about adapting the existing operations to compensate the influence of other users. For instance, incrementing the reference, if a component was inserted before. For example, if you work on the third paragraph and someone is inserting a new second parameter, you still want to work on the same paragraph, but it is no longer the third, but the forth.. PS: The second example will be answered tomorrow, I will have to focus on the soccer game.. [1] http://en.wikipedia.org/wiki/Operational_transformation [2] http://www.heise.de/developer/artikel/Synchronisationsalgorithmen-verstehen-1562877.html?artikelseite=1 (German - e.g. use Chrome browser context menu to translate) [3] http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation

Here the MCT representations of the second case that Patrick proposed. Please note my comment in the end. CASE 2 1. Original of 1st author <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph.</text:p> 2. 1st author changes text: <text:p>This is the original paragraph, created with change tracking on so seen as an added paragraph, which is then modified.</text:p> 3. 1st author changes text again: <text:p>This is the modified paragraph, created with change tracking on so seen as an added paragraph, which is further modified.</text:p> The intermediate step #2 should not be recorded because its a single editing session, therefore the change tracking // FILEPATH ./content.xml // DESCRIPTION:  The following is part of a content.xml file, similar abbreviated as in earlier examples <xmlns:text= urn:oasis:names:tc:opendocument:xmlns:text:1.0 xmlns:office= urn:oasis:names:tc:opendocument:xmlns:office:1.0 >     <!-- ... -->     <office:text >         <text:p>This is the modified paragraph, created with change tracking on so seen as an added paragraph, which is further modified.</text:p>     </office:text>     <!-- ... --> // FILEPATH ./meta.xml // DESCRIPTION:  Store all metadata of changes in the metadata file. <office:document-meta office:version= 1.3     xmlns:meta= urn:oasis:names:tc:opendocument:xmlns:meta:1.0     xmlns:office= urn:oasis:names:tc:opendocument:xmlns:office:1.0     xmlns:dc= http://purl.org/dc/elements/1.1/ >     <office:meta>         <meta:generator>ODFApp/1.0$Win32/123m1$Build-007</meta:generator>         <meta:creation-date> 20120618T145700+0100 </meta:creation-date>         <meta:initial-creator xml:id= User1 > 1st author </ meta:initial-creator >         <dc:creator xml:id= User1 >1st author </dc:creator>         <dc:date> 20120618T150024+0100 </dc:date><!-- time of change the ODF XML is related to -->         <dc:language>en-US</dc:language>         <meta:editing-cycles>2</meta:editing-cycles>     <office:meta> </office:document-meta>   // FILEPATH ./changes/undo.xml // DESCRIPTION:  Undo change operations are being stored in this file. The directory is useful for keeping changed binary data < undo xmlns= http://docs.oasis-open.org/ns/office/1.3/merge/ct# >     <del type= text time= 3m15s by= User1 s= /1/12 s= /1/21 />     <add type= text time= 3m24   by= User1 s= /1/12 >modified</add>     <add type= text time= 1m44s by= User1 s= /1/93 >, which is then further modified</add> </ undo > COMMENT : The operation based system makes the sort of changes and compression easy. The ODF application does not have to read several ODF XML files to do a forensic-like analysis to map back the user change-operation from the content. Instead all changes are listed separated from the content (undo.xml file). If multiple users would like to merge their changes, like a student sending his paper to several reviewers and receiving back their comments, it is possible to integrate all reviewer changes into a single document. This can done by only adjusting the parameter of existing changes, every time an external change was made prior (or above) an existing one. Like incrementing a position parameter, when content was added prior. In addition only the new changes need to be sent and applied to the current content. Not the complete document have to be read by the application. Think of collaboration on our specification, where one editor only changes a word in the end, megabytes of XML have to be sent for GCT & ECT, while for MCT only require the single change-operation. In addition the adjustment of several changes is straight forward and not a problem like in GCT/ECT, which have to deal during the comparison with changes on XML level, like different XML prefixes, different placement of span or automatic style names. Two examples on sorting and compressing of operations. EXAMPLE 1: Sorting Sort is easy as only the position parameter have to be adjusted. < undo xmlns= http://docs.oasis-open.org/ns/office/1.3/merge/ct# >     <add type= text time= 3m24   by= User1 s= /1/12 >modified</add>     <add type= text time= 1m44s by= User1 s= /1/93 >, which is then further modified</add> </ undo > is equal to < undo xmlns= http://docs.oasis-open.org/ns/office/1.3/merge/ct# >     <add type= text time= 1m44s by= User1 s= /1/85 >, which is then further modified</add>     <add type= text time= 3m24   by= User1 s= /1/12 >modified</add> </ undo > because the modified text was not added prior the index is eight (the amount of  characters of 'modified') less. Example 2: Compression Similar easy is the compression of operation. Multiple change operations as     <add type= text time= 1m53s by= User1 s= /1/104 >f</add>     <add type= text time= 1m53s by= User1 s= /1/105 >u</add>     <add type= text time= 1m54s by= User1 s= /1/106 >r</add>     <add type= text time= 1m54s by= User1 s= /1/107 >t</add>     <add type= text time= 1m55s by= User1 s= /1/108 >h</add>     <add type= text time= 1m56s by= User1 s= /1/109 >e</add>     <add type= text time= 1m56s by= User1 s= /1/110 >r</add>     <add type= text time= 1m57s by= User1 s= /1/111 > </add> are similar to the compressed operation     <add type= text time= 1m57s by= User1 s= /1/104 >further </add> Similar the following 5 operations of the above none-saved user actions: < undo xmlns= http://docs.oasis-open.org/ns/office/1.3/merge/ct# meta-file= ../meta.xml >     <add type= text time= 1m44s by= User1 s= /1/93 >, which is then modified</add>     <del type= text time= 1m47s by= User1 s= /1/104 s= /1/108 />     <add type= text time= 1m53s by= User1 s= /1/104 >further </add>     <del type= text time= 3m15s by= User1 s= /1/12 s= /1/20 />     <add type= text time= 3m24 by= User1 s= /1/12 >modified</add> </ undo > where compressed to the final change-tracking of < undo xmlns= http://docs.oasis-open.org/ns/office/1.3/merge/ct# >     <del type= text time= 3m15s by= User1 s= /1/12 s= /1/20 />     <add type= text time= 3m24   by= User1 s= /1/12 >modified</add>     <add type= text time= 1m44s by= User1 s= /1/93 >, which is then further modified</add> </ undo > Implementation Note: MCT can easily be added aside of the existing implementation. In the Apache (incubating) ODF Toolkit, I have added to the SAX handler the functionality to create components and operations from the loaded document aside the existing model (on a private branch). By doing so the operation can be easily extended incrementally, without any content get lost, because the components are accessed by component tree position (e.g. /1/1) and the reference to the existing model structure is returned. Best regards, Svante