Uploaded image for project: 'OASIS Open Document Format for Office Applications (OpenDocument) TC'
  1. OASIS Open Document Format for Office Applications (OpenDocument) TC
  2. OFFICE-3449

ODF 1.2 CD05 Part 1 5.5.3 Text Insertion Interoperable Definition Required

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Deferred
    • Priority: Blocker
    • Resolution: Later
    • Affects Version/s: ODF 1.2 CD 05
    • Fix Version/s: ODF-Next
    • Component/s: Part 1 (Schema), Text
    • Labels:
      None
    • Proposal:
      Hide

      [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.

      Show
      [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.
    • Resolution:
      Hide

      This issue is deferred to ODF-Next absent any offer by the appropriate experts to remedy the defects that prevent independent implementation of this feature with any level of interoperabilty.

      Show
      This issue is deferred to ODF-Next absent any offer by the appropriate experts to remedy the defects that prevent independent implementation of this feature with any level of interoperabilty.

      Description

      This is related to ODF-3448 and related issues around tracked changes.

      There is actually no description of what constitutes an insertion and what it takes to reject one. (Acceptance is easy).

      All we have said is that <text:change-start> and a matching <text:change-end> element bound the insertion and associate it with a <text:insertion> element.

      But the span of markup betweem a <text:change-start> to its corresponding <text:change-end> has all the characteristics of a selection. And rejecting the insertion is an act of deletion. Although that deletion is presumably not tracked, a consumer that supports insertion rejection, must know how to heal the removel of the inserted markup similar to ways that markup is healed around the scar of a tracked deletion.

        Attachments

          Activity

            People

            • Assignee:
              orcmid Dennis Hamilton (Inactive)
              Reporter:
              orcmid Dennis Hamilton (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: