ODF 1.2 CD05 Part 1 5.5.3 Text Insertion Interoperable Definition Required

[Dennis' proposal:] Again ,the stakeholders of this provision must assist in arriving at an interoperably-implementable description of what current implementations manage for ODF 1.0/1.1. 1. Define what constitutes a legitimate single insertion selection and how it relates to other occurrences of insertion selections. Must they be non-overlapping? May they be nested? We want a case for allowed insertion selections that are implemented and that shall be supported by a conforming implementation that supports tracked changes shall be able to present the insertion (if that is a consumer capability) and to reject the insertion (if rejection is a consumer capability). [Note: there is no concern, here, for what a producer might turn into multiple insertions to accomodate an operation provided for processing of a document, only what one must be prepared to recognize as a single selection in the document. 2. How much of healing across a tracked deletion is involved when healing across the deletion that rejection of an insertion is? 3-4 omitted because they seem to be irrelevant in this case. 5. Edge cases: Whether deletions can occur that remove part of an insertion selection, and if so, what is done about the curing the broken connection between <text:change-start> and its matching <text:change-end>? I have the same sense of what works as implementation-defined and implementation-dependent requiring that there be some useful remainder that can be interoperably implemented and that a consumer can detect whether it can deal with whatever else shows up in regard to tracked insertions. [Note: I have stayed away from use cases, although there is obviously an interest among implementers in seeing how what is provided works with interesting cases, such as a cut and paste operation that leaves deletions and results in insertions. Also pasting over a selection leads to deletions and insertions at the destination. I don't think we can speak to that, although there is some concern that what is well-defined in the format can be usable in such manipulations. Undo, which does not leave residue in conforming markup of the produced document, is also a consideration for implementers nonetheless.] This is simpler than tracked deletion alt [Oliver's proposal:] Use the information given at Dennis' proposal for an improved or new ODF change tracking for the next version of ODF.