This is a draft, more references and responses needed.
ECT (Extended CT) Issues for consensus report
ECT-Issue-1: Scope - covers some of text, excludes presentation and excludes spreadsheet
ADC requirements state: "2.4 Track all possible types of change - track all types of change, e.g. across hierarchy, tables, styles etc." Noted some members of ADC SC do not think this is a necessary requirement, but there have been specific requests for spreadsheets to be included in CT.
ECT proposal states, "This proposal focuses on the need for robust change tracking in text documents, the primary user scenario based on customer feedback." Therefore if we move forward with ECT the other areas will not be addressed, at least initially. Work is still needed to complete the current scope and then more work will need to be done to extend to new areas.
ECT-Issue-2: Not fully backward compatible with ODF 1.2
ECT proposal states, "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. ..."
"In addition to supporting new use cases as described below, we propose expanding the prose that describes the current change tracking support to make its intended use and scope more explicit." It is also agreed that the current CT in ODF is broken and needs to be re-defined, see below the blog and also the supplement which has a long description of how a new representation is better than the existing one. At this time there is no decision as to whether an existing ODF with CT will or will not be valid ECT.
Original problem statement in blog above:
- ODF 1.1 has a very limited description of tracked changes, covered in only 4 pages of the specification. ODF 1.1 does not does explain how to implement change tracking for many of Word’s commonly used features, and in some cases it is not even clear if the ODF mechanism makes it possible at all.
- As a result of these differences, we found that it is not possible to implement robust and reliable tracked changes with ODF; even very simple concepts, such as deleting a row from a table, are not supported by any existing ODF implementation of tracked changes
- There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes.
Some re-definition of the exiting CT in ODF is needed but ECT adopts similar styles and conventions and therefore maintains some general compatibility.
JH: Which allows implementations to continue to leverage existing code, bug fixes and other work toward interoperability.
ECT-Issue-3: No solution for split inserts
UC1 discussion included comment "Some discussion about what is allowed between a change-start and a change-end element and whether these both need to have the same parent element - John said there were no rules about this. The implications of this have not been thought through yet, but splitting change-start and change-end across element boundaries is a known problem in current ODF change-tracking."
JH: UC8 examined a case of a pair of start and end elements and an ECT solution was presented (and authored by another member of the SC).
ECT-Issue-4: The 'bucket' approach means undo is only executed correctly if in reverse order
Noted that in ECT there is no way to represent changes to attributes except by delete and replace element (and its content if any). UC1 discussion: "Robin asked why the ECT does not have a way of representing attribute change. John said that the previous answer applies to this as well, and the intention is to handle this the same way as current ODF change-tracking." The bucket approach caches an existing bucket (element) and replaces it with a new one with different attributes and potentially content. Therefore an undo of any particular change resets the element to how it was before the change. Thus for changes 1,2,3 undo of 3 then 2 leaves state 1, which is correct. Undo of 2 then 3 leaves state 2 which is not correct.
This is a fundamental problem for changes at the atomic level, e.g. GCT has the same issue for attribute values, but in ECT this issue is magnified by the use of buckets.
JH: John addressed this at length in e-mail, with examples, challenging this blanket claim. See the e-mail threads (split thread) “Notes on Conference call to discuss use case solutions UC4-UC8” - http://markmail.org/search/%22Notes+on+Conference+call+to+discuss+use+case+solutions+UC4-UC8%22+list:org.oasis-open.lists.office-collab+order:date-forward
ECT-Issue-5: Possible inconsistent handling of spans and other elements
UC1 discussion: "Noted that ECT seems to be able to add/delete spans and adjust span attributes without add/delete of content and so perhaps the same technique can be used for list levels and other areas. It seems inconsistent as it stands."
JH: I may not remember correctly two months on, but since that comment was taken from the discussion of UC1, I believe it was made in passing about making ECT use the method to track style changes (in <text:span>) for changes in list structures, rather than the insert/delete style bucket approach. I see this as an instance of the general question about the bucket architecture and think that approach is more straightforward, if potentially more verbose.