After all of the emphasis in the ECT proposal that this is just to illustrate a direction that can be taken, and it remains to be determined what the appropriate granularity is (where there is already not any, presumably), why are we making these detail level comparisons as if that is a specific detail of the ECT proposal? Furthermore, what ODF? already does is not factored in. The ECT proposal does not dig into ODF?, as far as I can tell, but if there is already ODF? attention to the particular case, that is what ECT should certainly take as a point of departure. It is already the case that <text:p> being at the top level is not a condition. Note that <text:list-item> allows, in its children, any number of <text:h>, <text:p> and <text:list> elements, so it is highly recursive. This is completely illustrated where I show exactly what Libre Office 3.3.2 does (along with a bug) in my "Analysis of Current ODF Deletion Tracking Upload":
http://www.oasis-open.org/committees/document.php?document_id=41714 (Although the paragraph following the list is top-level in the example I extracted from the LO 3.3.2 document, I could have arranged for all of them to be nested down in some higher-level structure.) If you look up the change-marks pattern in the schema, or check on the definitions in the ODF 1.2 specifications for <text:change>, <text:change-start>, and <text:change-end> you'll see that these three markers are legitimate elements wherever paragraph-content, text-content, and header-footer content are allowed. In short, these three elements, one for showing where a deletion restore point is, one for showing where an insertion starts, another for where an insertion ends, can appear as element children of any of the following elements, to name a few: <text:a>, <draw:textbox>, <text:h>, <text:p>, <text:meta>, <text:meta-field>, <text:span>, <text:section>, <text:note-body>, <text:ruby-base>, and <office:change-info>. There is no limitation on the context of these elements other than prescribed by the schema. I have no idea what it means to say code paths would have to be duplicated in these cases. That seems to have no bearing on how it works in practice. To make life even more exciting, change-mark elements are also permitted as element children of <text:index-body> and <text:index-title>, which means in every form of index in ODF 1.2 (TOC, list of figures, etc.). In regard to what Andreas asked, ODF? already allows the change marks in <table:table-cell> and <table:covered-table-cell>. However, an <office:spreadsheet> and its <table:tracked-changes> does not allow for <text:tracked-changes> so those marks are allowed but not meaningful in a <table:table-cell> of a spreadsheet <table:table> (except possibly under an obscure embedded-spreadsheet edge case). This is clearly something to be addressed in extending coverage for change-tracking in ODF. - Dennis