OpenDocument - Adv Document Collab SC

  • 1.  1. Backward compatibility: what are requirements?

    Posted 05-11-2011 13:24
    Should ODF-Next CT be Backward Compatible with ODF 1.2? The issue of backward compatibility has been raised in a number of emails. It is an important issue because if we are trying to maintain backward compatibility with existing change tracking within ODF 1.2, then this would seem to be an important constraint on the ECT and to rule out the GCT solution. Backward compatibility was not one of our initial requirements, though there was agreement that we need to be able to convert from the existing change tracking mechanism to any new one. To maintain strict backward compatibility (of the format, not the applications) would mean that the change tracking as represented in ODF 1.2 is valid change tracking in ODF-Next. Having reviewed all the comments that I can find on this issue (see below) I do not think anyone is arguing for this position, although a principle of the ECT is that this would be possible. The consensus seems to be that CT does not work the way it is currently specified. If that is the case, then what are the aspects of CT in ODF 1.2 that are important and good and that we are trying to keep? This was a specific question raised in our initial call. See http://wiki.oasis-open.org/office/Change%20Tracking%20Requirements for the list from this initial conference call.   The ECT objective is to build on existing patterns and code, but there seems to be evidence (and probably consensus) that some of the patterns are not worth building on (see last comment in 5 and also 6 and 7 below). There is also the point that we might be throwing out any existing CT interoperability, but as Microsoft did not implement CT at all in their ODF and There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes. (comment 8 below) this also seems to be of limited value. From the comments, it is difficult to discern what is of real value in the existing CT, apart from some general features that have been identified. If there is more specific real value here, then we need to identify it. COMMENTS MADE IN PREVIOUS DISCUSSIONS/EMAILS These are not in a particular order, and I have tried not to quote anything out of context (my apologies if I have done so), but rather to save others going back through the stack of emails etc. 1. In our initial conference call this point was made:   1.5 Can convert from existing change tracking mechanism to new one    - all changes recorded in current format can be converted, i.e. a defined way to move to the new format 2. extended-ct-proposal http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/41699/extended-ct-proposal.odt The basic idea behind this proposal is to preserve the existing ODF change tracking and extend it to support missing use cases.  We believe this best preserves backward compatibility with existing implementations and makes best use of existing patterns and code.  It also maintains the current model of ignoring changes for applications that do not support change tracking. 3. John H email 2011-04-21 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00070.html I mentioned on this week’s call we have not discussed high-level guiding tenets such as how we want to handle backward compatibility, ... I think there is another large CT-specific question we haven’t addressed – a decision on whether we want to discard and replace the existing ODF 1.0 - 1.2 CT model.  This has significant impact on existing implementations and the state of interoperability they have built up to at this point*.  As Rob noted in the call, the TC’s rough, overall tenets have been that backward compatibility is important, it’s open to large breaking changes though more for new major versions of ODF rather than minor versions and to not tie ODF too much to any one implementation in the future. * but see 8 below 4. Doug M email 2011-01-21 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00009.html One thing that struck me was the combination of “1.5 Can convert from existing change tracking mechanism to new one” and “2.2 Interoperability with other formats.” These two requirements may be at odds with one another: is it actually possible to define change tracking in a way that maps to the existing approach as well as the approach used in OXML, for example? I think that we should take into consideration the magnitude of existing usage of ODF and OXML change tracking, and prioritize accordingly, in the interest of maximizing the opportunities for use of the new approach we’re designing. I’m sure there are other perspectives on this, but it’s probably a conversation worth having. Tristan M comments: As far as requirement 1.5 goes, I think this would only be a one-way conversion i.e. converting from the existing change-tracking mechanism to the new one. The resultant document would of course have the same limitations as the existing change-tracking format in that it would only represent those changes that can currently be tracked. Converting back the other way is not necessary and indeed need not be possible. The conversion would either be performed via an application's internal model in a load-save cycle and/or could be written as an XSLT script to generate the new format. If we limit conversion to this direction only, I see no reason why interoperability with other formats would need to be compromised. 5. Ganesh P email 2011-04-01 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00000.html 1. The supplement seems to introduce a new way to handle delete changes ( it is called as the Insert/Delete style and is conceptually different from the ODF 1.2 delete change handling mechanism ). So, the new mechanism should be applied to the <p> to <p> and <p> to <h> merges too ( The two use-cases that are explicitly handled in the current ODF 1.2 specification ) . Right ? John H comments: The reference to Insert/Delete style is the same pattern from the first document.  I gave it a name here to differentiate it from the “paragraph style” approach I wanted to at least bring up in case it was worth discussion. 2. Doesn't the introduction of the new mechanism break backward compatibility to the old ODF 1.2 change tracking format. John H comments: The general question of backward compatibility needs to be looked at in detail across the board for both proposals, particularly with input from implementers who have existing change tracking support.  I think both proposals may have back-compat issues.  Depending on various choices the SC would need to make about the specific changes it would introduce, I think the extended one could be designed to be additive only – introduce only new mechanisms. Relevant to this point is also this earlier blog from Doug M: http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx I put paragraphs in quotes there for a reason: in the simple example we’re looking at here, I did not delete a paragraph, I deleted a word from inside a paragraph.  So why is the deleted text wrapped inside a paragraph element? The answer is that the ODF spec requires deleted content (as contained in a text:deletion element) to be schema-compliant, regardless of whether the deleted region was a well-formed element or (as in this case) merely a fragment within some other structure, such as a word within a paragraph. This is the source of the problem I alluded to above, for implementers who choose to support ODF tracked changes.  Each implementer must decide how to synthesize markup to make each piece of deleted content into well-formed XML, and then later – when it comes time to accept or reject the change – each implementer must make decisions about how to distinguish between the synthesized packaging and the deleted content itself. Unfortunately, the ODF specification doesn’t provide much guidance on this complex topic. 6. Andreas G email 2011-05-06 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201105/msg00001.html ODF1.2 simply reiterates the ODF1.0/1.1 description of change tracking for spreadsheets.  Neither of them I find understandable, for example the distinction between deletions and cutoffs raises the question (at least in my mind) whether the table:position value refers to the current col/row numbering or the col/row numbering at the time of the change. The Standard appears mute on this. Moreover in the current discussion there is concern about buckets . The current spreadsheet change tracking model appears to considers each table cell as a bucket which seems quite coarse to me. Based on the current state of the description and specification this does not appear implementable to me. 7. Dennis H in document ODF 1.0-1.2 CURRENT DELETION-TRACKING FORENSICS http://www.oasis-open.org/committees/document.php?document_id=41714 Deletion tracking is underspecified in the current ODF 1.0-1.2 specifications. However, it is quite successfully implemented, suggesting that the problem is in the specification failing to capture the necessary information from which to make independent interoperable implementations. This note demonstrates the “ground truth” for current deletion tracking. It is offered to indicate that there is much that needs to be comprehended in the current ODF 1.x practice so that it can be preserved in any improvement of the specification and the cases that are covered. 8. Doug H blog http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes. -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML 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


  • 2.  RE: [office-collab] 1. Backward compatibility: what arerequirements?

    Posted 05-12-2011 21:32
    > To maintain strict backward compatibility (of the format, not the applications) would mean that the change tracking as represented in ODF 1.2 is valid change tracking in ODF-Next. Having reviewed all the comments that I can find on this issue (see below) I do not think anyone is arguing for this position Nobody has argued for it but we haven’t really discussed it until now.  This is the key question.  Are we making an explicit decision to make a breaking file format change such that ODF 1.3/2.0/whatever documents are not readable by users of existing implementations without some sort of backport update (or forcing those users to upgrade)?   I think the answer can legitimately fall either way.  My main reason for bringing up backward compatibility was that it impacts users and we ought to be clear with ourselves what impact the next ODF will have on them.  This affects users primarily in their ability to share files with one another across older and newer versions of applications.  We might agree to say this is an implementation issue and implementers must decide how their app will address the transition from 1.2 to 1.3/2.0 for their own user base – e.g., do nothing and let users figure it out, handle reading/saving both formats so users can choose, releasing backports for older versions, etc.  We might also decide that the next ODF is more 1.3-ish than 2.0-ish and breaking changes should only occur in major version changes.  I’m not aware of any guiding principles from the main TC on what the next ODF is all about, so we may not yet know whether it’s more minor or major version oriented.   > there seems to be evidence (and probably consensus) that some of the patterns are not worth building on (see last comment in 5 and also 6 and 7 below) > and "There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes." I wouldn’t conclude that particular flaws in the specification of the current change tracking invalidate the patterns it defines.  I believe most of the complaints below are in regard to the insufficient definition of how to handle certain types of deletions.  The ECT proposal recommended improving this, as did a couple people during a conference call discussion, as I recall.  Of course, we haven’t yet looked at how to make it more explicit since we don’t yet have a decision on whether it’s to be fixed or thrown out.   > 6. Andreas G email 2011-05-06 Andreas makes some good comments about spreadsheet CT.  I’d studied that part of the standard ( § 9.9 in ODF 1.2) and couldn’t figure out a few parts of it that were underspecified as I couldn’t get various applications to produce the markup.  Similar to the above notion about better specifying text deletion, that same principle could be applied to parts of spreadsheet CT to make it more clear, implementable and interoperable.  I think Andreas’ expertise (as well as other longtime ODF people who may understand that section better than I) could effect changes here that I suspect will be both relatively small and yield significant improvement.   John   From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] Sent: Wednesday, May 11, 2011 6:24 AM To: office-collab@lists.oasis-open.org Subject: [office-collab] 1. Backward compatibility: what are requirements?   Should ODF-Next CT be Backward Compatible with ODF 1.2? The issue of backward compatibility has been raised in a number of emails. It is an important issue because if we are trying to maintain backward compatibility with existing change tracking within ODF 1.2, then this would seem to be an important constraint on the ECT and to rule out the GCT solution. Backward compatibility was not one of our initial requirements, though there was agreement that we need to be able to convert from the existing change tracking mechanism to any new one. To maintain strict backward compatibility (of the format, not the applications) would mean that the change tracking as represented in ODF 1.2 is valid change tracking in ODF-Next. Having reviewed all the comments that I can find on this issue (see below) I do not think anyone is arguing for this position, although a principle of the ECT is that this would be possible. The consensus seems to be that CT does not work the way it is currently specified. If that is the case, then what are the aspects of CT in ODF 1.2 that are important and good and that we are trying to keep? This was a specific question raised in our initial call. See http://wiki.oasis-open.org/office/Change%20Tracking%20Requirements for the list from this initial conference call.   The ECT objective is to build on existing patterns and code, but there seems to be evidence (and probably consensus) that some of the patterns are not worth building on (see last comment in 5 and also 6 and 7 below). There is also the point that we might be throwing out any existing CT interoperability, but as Microsoft did not implement CT at all in their ODF and "There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes." (comment 8 below) this also seems to be of limited value. From the comments, it is difficult to discern what is of real value in the existing CT, apart from some general features that have been identified. If there is more specific real value here, then we need to identify it. COMMENTS MADE IN PREVIOUS DISCUSSIONS/EMAILS These are not in a particular order, and I have tried not to quote anything out of context (my apologies if I have done so), but rather to save others going back through the stack of emails etc. 1. In our initial conference call this point was made:   1.5 Can convert from existing change tracking mechanism to new one    - all changes recorded in current format can be converted, i.e. a defined way to move to the new format 2. extended-ct-proposal http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/41699/extended-ct-proposal.odt "The basic idea behind this proposal is to preserve the existing ODF change tracking and extend it to support missing use cases.  We believe this best preserves backward compatibility with existing implementations and makes best use of existing patterns and code.  It also maintains the current model of ignoring changes for applications that do not support change tracking." 3. John H email 2011-04-21 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00070.html "I mentioned on this week’s call we have not discussed high-level guiding tenets such as how we want to handle backward compatibility, ..." "I think there is another large CT-specific question we haven’t addressed – a decision on whether we want to discard and replace the existing ODF 1.0 - 1.2 CT model.  This has significant impact on existing implementations and the state of interoperability they have built up to at this point*.  As Rob noted in the call, the TC’s rough, overall tenets have been that backward compatibility is important, it’s open to large breaking changes though more for new major versions of ODF rather than minor versions and to not tie ODF too much to any one implementation in the future." * but see 8 below 4. Doug M email 2011-01-21 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00009.html "One thing that struck me was the combination of “1.5 Can convert from existing change tracking mechanism to new one” and “2.2 Interoperability with other formats.” These two requirements may be at odds with one another: is it actually possible to define change tracking in a way that maps to the existing approach as well as the approach used in OXML, for example? I think that we should take into consideration the magnitude of existing usage of ODF and OXML change tracking, and prioritize accordingly, in the interest of maximizing the opportunities for use of the new approach we’re designing. I’m sure there are other perspectives on this, but it’s probably a conversation worth having." Tristan M comments: "As far as requirement 1.5 goes, I think this would only be a one-way conversion i.e. converting from the existing change-tracking mechanism to the new one. The resultant document would of course have the same limitations as the existing change-tracking format in that it would only represent those changes that can currently be tracked. Converting back the other way is not necessary and indeed need not be possible. The conversion would either be performed via an application's internal model in a load-save cycle and/or could be written as an XSLT script to generate the new format. If we limit conversion to this direction only, I see no reason why interoperability with other formats would need to be compromised." 5. Ganesh P email 2011-04-01 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00000.html "1. The supplement seems to introduce a new way to handle delete changes ( it is called as the Insert/Delete style and is conceptually different from the ODF 1.2 delete change handling mechanism ). So, the new mechanism should be applied to the <p> to <p> and <p> to <h> merges too ( The two use-cases that are explicitly handled in the current ODF 1.2 specification ) . Right ? John H comments: "The reference to Insert/Delete style is the same pattern from the first document.  I gave it a name here to differentiate it from the “paragraph style” approach I wanted to at least bring up in case it was worth discussion." "2. Doesn't the introduction of the new mechanism break backward compatibility to the old ODF 1.2 change tracking format." John H comments: "The general question of backward compatibility needs to be looked at in detail across the board for both proposals, particularly with input from implementers who have existing change tracking support.  I think both proposals may have back-compat issues.  Depending on various choices the SC would need to make about the specific changes it would introduce, I think the extended one could be designed to be additive only – introduce only new mechanisms." Relevant to this point is also this earlier blog from Doug M: http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx "I put paragraphs in quotes there for a reason: in the simple example we’re looking at here, I did not delete a paragraph, I deleted a word from inside a paragraph.  So why is the deleted text wrapped inside a paragraph element? "The answer is that the ODF spec requires deleted content (as contained in a text:deletion element) to be schema-compliant, regardless of whether the deleted region was a well-formed element or (as in this case) merely a fragment within some other structure, such as a word within a paragraph. "This is the source of the problem I alluded to above, for implementers who choose to support ODF tracked changes.  Each implementer must decide how to synthesize markup to make each piece of deleted content into well-formed XML, and then later – when it comes time to accept or reject the change – each implementer must make decisions about how to distinguish between the synthesized packaging and the deleted content itself. "Unfortunately, the ODF specification doesn’t provide much guidance on this complex topic." 6. Andreas G email 2011-05-06 http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201105/msg00001.html "ODF1.2 simply reiterates the ODF1.0/1.1 description of change tracking for spreadsheets.  Neither of them I find understandable, for example the distinction between deletions and cutoffs raises the question (at least in my mind) whether the table:position value refers to the current col/row numbering or the col/row numbering at the time of the change. The Standard appears mute on this. Moreover in the current discussion there is concern about "buckets". The current spreadsheet change tracking model appears to considers each table cell as a bucket which seems quite coarse to me. "Based on the current state of the description and specification this does not appear implementable to me." 7. Dennis H in document ODF 1.0-1.2 CURRENT DELETION-TRACKING FORENSICS http://www.oasis-open.org/committees/document.php?document_id=41714 "Deletion tracking is underspecified in the current ODF 1.0-1.2 specifications. However, it is quite successfully implemented, suggesting that the problem is in the specification failing to capture the necessary information from which to make independent interoperable implementations. "This note demonstrates the “ground truth” for current deletion tracking. It is offered to indicate that there is much that needs to be comprehended in the current ODF 1.x practice so that it can be preserved in any improvement of the specification and the cases that are covered." 8. Doug H blog http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx "There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes." -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML" 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 from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 3.  RE: [office-collab] 1. Backward compatibility: what are requirements?

    Posted 05-12-2011 23:12
    In case it was not clear from discussions on the calls, I for one consider it critical that the question of preservation of change-tracking in existing ODF 1.0/1.1/1.2 documents be carefully addressed and that preservation be abandoned only as a last resort and to the least degree possible. - Dennis ELABORATION In particular, where documents are records and may be curated and authenticated in some way (e.g., with digital signatures), it may not be possible to expect upgrading or conversion, and resigning may be neither possible nor legally acceptable. While it is unfortunate that the specification is so poor in this respect (and also for insertion, not just deletion) and that implementations demonstrate defects of various sorts and may be incomplete as well, it is clear that there is something out there in native ODF software products that are claimed to support the ODF specifications. We need to figure out how to address that for text and for spreadsheets. We also know, from limited experimentation, that there is a degree of cross-format interoperability between widely-used native ODF implementations via their import/export support for formats such as binary .DOC-format files. These are matters of some interest to the community of users for "open standard" document formats, and there has been strong advocacy around what take-up of such formats gives assurance to. While it is not OASIS or the ODF TC that has offered such assurances, we need to be mindful that those who mandate ODF in various situations probably see no distinction. Of course, if none with expertise in such implementation are able or willing to assist the ODF TC in providing a rigorous specification of the provision sufficient for independent implementation, the ODF TC is helpless. We can then not do much to have to have existing ODF change-tracking provisions as a basis for adequate specification of what practice is along with extension to handle further use cases. It then becomes rather embarrassing that we have perpetuated provisions from ODF 1.0 through ODF 1.2 that we lack the ability to specify with any clarity whatsoever. That, in turn, raises serious questions about the process capability of this TC to fulfill its charter.


  • 4.  RE: [office-collab] 1. Backward compatibility: what are requirements?

    Posted 05-16-2011 13:23
    Dennis, do you have an opinion to offer on the two change tracking proposals currently under consideration? You seem to be beating up on a third option -- doing nothing -- that is not something that is under consideration at this point. Or at least I have not heard anyone seriously offer that as a proposal. -Rob


  • 5.  RE: [office-collab] 1. Backward compatibility: what are requirements?

    Posted 05-16-2011 16:08
    My understanding is that ECT takes the existing change tracking as a basis: "The basic idea behind this proposal is to preserve the existing ODF change tracking and extend it to support missing use cases. We believe this best preserves backward compatibility with existing implementations and makes best use of existing patterns and code. It also maintains the current model of ignoring changes for applications that do not support change tracking. A relatively small number of additions to the existing capability can enable a core set of previously unsupported use cases." I am assuming that part of that effort would be to rationalize the specification of the ODF 1.0/1.1/1.2 change tracking and elaborate further for additional cases. I'm not sure how it could be properly extended otherwise. So my inclination is to take the ECT direction with details based on what it takes to make it all come out sound. - Dennis PS: I have been surveying implementations of change-tracking in a variety of products. It is sobering to note that none of them are very consistent and seem to have a lot of seemingly-random aberrations, with the degree of interoperability (via format converters or common native format) of change tracking a veritable shambles. The most reliable case I have found is how Google Docs avoids doing change tracking altogether but provides a kind of Wiki-style rejection control -- you can always revert to an earlier stage but you can't deal with changes individually. Some products base their change-tracking on document comparison, which doesn't really apply to our case and has uneven results, especially if it is inconsistent with what change-tracking does. I am sure there are projects that may do change-tracking superbly but apparently not in the office-productivity document space. It is daunting to consider that the ODF 1.0/1.1/1.2 approach, as sketchy as it is, has the seeds of one of the best change-tracking mechanisms ever. (I will keep searching.)


  • 6.  Re: [office-collab] 1. Backward compatibility: what are requirements?

    Posted 05-17-2011 15:36
    I'd like to explore one of your points, Dennis, where you say: Some products base their change-tracking on document comparison, which doesn't really apply to our case and has uneven results, especially if it is inconsistent with what change-tracking does. The use of change tracking in conjunction with document comparison is actually an important use case which should not be dismissed. Let me give you two examples. [1] A company involved in financial and legal printing wanted to use ODT and OpenOffice.org as the basis for preparing large legal documents, which contained a lot of financial tables. These documents had to be submitted to regulators, who made comments and required certain revisions. There was a requirement to resubmit the updated document to the regulators, and show precisely what changes had been made. There was no way that this could have been done with change tracking, even if the change tracking in ODT had been sufficiently powerful. One reason for this is that   they did not want the regulators to see intermediate versions, and another reason was that multiple authors were working on the document. Therefore it was necessary to do a detailed document comparison in order to provide the regulators with what they required. We were asked to write a comparator for ODT for this specific purpose, including detailed comparison of the financial tables (this is now available as a free extension to OOo and is based on ODT 1.1). [2] This company also had a requirement for multiple authors to work on a single large (several hundred pages) document simultaneously. Therefore they needed to be able to merge the edits from multiple authors together into a single document. Again, they asked us to write software to do this based on ODT. In this case we had to use the change track facilities in order to allow the 'chief' editor to review edits by all the other editors and accept or reject them for a final version of the document. Again, this was based on document comparison because intermediate changes were not relevant and because of the complexity of merging tracked changes together. You could argue that the first case here, document comparison, is not a change tracking use case because there is no requirement to be able to accept or reject the changes. Rather there is a requirement to be able to see where changes have been made - but this is a really important use case. This may be a useful distinction which we need to explore further, for example rather than talking about 'change tracking', we could talk about 'edit tracking' and 'revision tracking'. These might be defined as follows: 'Edit tracking' is the ability to record edits made in an editing application in order that they can be viewed, accepted or rejected at a later date. 'Revision tracking' is the ability to record changes to a document such that these changes can be displayed in a document viewer, but there is no requirement that the changes can be undone. I think we are beginning to uncover some of the reasons behind our differences in opinion in terms of requirements. Regards, Robin On 16/05/2011 17:07, Dennis E. Hamilton wrote: 004401cc13e3$6c4a3bd0$44deb370$@acm.org type= cite > My understanding is that ECT takes the existing change tracking as a basis: The basic idea behind this proposal is to preserve the existing ODF change tracking and extend it to support missing use cases. We believe this best preserves backward compatibility with existing implementations and makes best use of existing patterns and code. It also maintains the current model of ignoring changes for applications that do not support change tracking. A relatively small number of additions to the existing capability can enable a core set of previously unsupported use cases. I am assuming that part of that effort would be to rationalize the specification of the ODF 1.0/1.1/1.2 change tracking and elaborate further for additional cases. I'm not sure how it could be properly extended otherwise. So my inclination is to take the ECT direction with details based on what it takes to make it all come out sound. - Dennis PS: I have been surveying implementations of change-tracking in a variety of products. It is sobering to note that none of them are very consistent and seem to have a lot of seemingly-random aberrations, with the degree of interoperability (via format converters or common native format) of change tracking a veritable shambles. The most reliable case I have found is how Google Docs avoids doing change tracking altogether but provides a kind of Wiki-style rejection control -- you can always revert to an earlier stage but you can't deal with changes individually. Some products base their change-tracking on document comparison, which doesn't really apply to our case and has uneven results, especially if it is inconsistent with what change-tracking does. I am sure there are projects that may do change-tracking superbly but apparently not in the office-productivity document space. It is daunting to consider that the ODF 1.0/1.1/1.2 approach, as sketchy as it is, has the seeds of one of the best change-tracking mechanisms ever. (I will keep searching.)