OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Cross-Cutting Deletions in Lists (re: OFFICE-2621)


I was reminding myself about the state of ODF change-tracking by reviewing the JIRA issues on the subject.  This comment relates to OFFICE-2621 at <https://issues.oasis-open.org/browse/OFFICE-2621>, but it is probably a new issue.

I notice there is a misunderstanding in the comment that OFFICE-2621 pertains to.

I also notice that the resolution of OFFICE-2796, which repaired section 5.5.4 does *not* address the underlying issue.

THE FIRST MISUNDERSTANDING

Ganesh Paramasivam raises a question about deletion across items in this kind of list.

  1. aaaaaaaaaaaa
  2. bbbbbbbbbbbb
  3. cccccccccccc

The deletion is done with a single selection (that also includes the auto-numbered 2).

  1. aaaaaa------
  2. ------bbbbbb
  3. cccccccccccc

The ordinary result, when the deletion is accepted (or is not tracked), is

  1. aaaaaabbbbbb
  2. cccccccccccc

Ganesh was puzzled how this could involve paragraphs, based on a mistaken understanding of the schema for lists and list items.  In fact, list items have as their content any number of paragraphs, headers, and lists. 

So, using HTML-like markup for simplicity, what we have is

  <list><li><p>aaaaaaaaaaaa</p></li>
        <li><p>bbbbbbbbbbbb</p></li>
        <li><p>cccccccccccc</p></li>
  </list>

The deletion typically produces this:

  <list><li><p>aaaaaa<text:change/>bbbbbb</p><li>
        <li><p>cccccccccccc</p></li>
  </list>

Now, it could have been turned into two changes, preserving three list items.  But that is not the common treatment in ODF implementations.  (That is what Microsoft Office Word does.  One can reject the splicing of the list items, treated as a format change, separately from rejecting the deletion of the character strings. I don't claim it is better, just different.  At least it preserves everything properly.)

The <text:change/> has to locate a <text:deletion> element, that must somehow have this content, based on what the schema allows (simplified again):

   <list><li><p>|aaaaaa</p></li><p>bbbbbb|</p></li></list>

Where the part between the fences, | ... | is literally is what was deleted when comparing the saved documents.

I suggest that 5.5.4, which only describes reversal of the deletion, does not account for this very well, if at all.  You might be able to read the business about unravelling start and end tags to account for this.

THE SECOND MISUNDERSTANDING

Consider this case:

  1. aaaaaaaaaaaa
  2. bbbbbbbbbbbb
     a. cccccccccccc
        i. dddddddddddd
        ii. eeeeeeeeeeee
     b. fffffffffff
  3. gggggggggggg

And let this be the deletion:
       
  1. aaaaaaaaaaaa
  2. bbbbbb------
     a. ------cccccc
        i. dddddddddddd
        ii. eeeeeeeeeeee
     b. fffffffffff
  3. gggggggggggg 

Note that, this case, the deletion not only cross-cuts two list items, it cross-cuts over the beginning of a sublist.

I checked this with an existing ODF implementation and Microsoft Office.  Both allow this case.  The question for ODF is what happens with the cut-through sublist beginning.

If you look at it with changes not shown, it will appear as

  1. aaaaaaaaaaaa
  2. bbbbbbcccccc
        i. dddddddddddd
        ii. eeeeeeeeeeee
     b. fffffffffff
  3. gggggggggggg   

But if the document is saved and reloaded, in at least one current ODF implementation, it comes back as

  1. aaaaaaaaaaaa
  2. bbbbbb------
  3. ------cccccc
        i. dddddddddddd
        ii. eeeeeeeeeeee
     b. fffffffffff
  4. gggggggggggg

(and note that item (b) is orphaned with no (a)).

And rejecting the deletion produces

  1. aaaaaaaaaaaa
  2. bbbbbbbbbbbb
  3. cccccccccccc
        i. dddddddddddd
        ii. eeeeeeeeeeee
     b. fffffffffff
  4. gggggggggggg

The question is, of course, what is in the list and the <text:deletion> that are saved and how did it the original unchanged text get lost in this way?


 -- Dennis E. Hamilton
    dennis.hamilton@acm.org    +1-206-779-9430
    https://keybase.io/orcmid  PGP F96E 89FF D456 628A

PS: Here's what I found in the ODF.  I will be necessary to splice some line breaks back together, and the list server might have problems with the angle brackets: 


<office:text>
    <text:tracked-changes>
        <text:changed-region xml:id="ct242184032" text:id="ct242184032">
            <text:deletion>
                <text:list xml:id="list4891716330041825216"
                           text:style-name="L1">
                    <text:list-item>
                        <text:p text:style-name="P1">bbbbbb</text:p>
                        <text:list>
                            <text:list-item>
                                <text:p text:style-name="P1">cccccc</text:p>
                            </text:list-item>
                        </text:list>
                    </text:list-item>
                </text:list>
            </text:deletion>
        </text:changed-region>
    </text:tracked-changes>

    <text:list xml:id="list143629373148105" text:continue-numbering="true" text:style-name="L1">
        <text:list-item>
            <text:p text:style-name="P1">aaaaaaaaaaaa</text:p>
        </text:list-item>
        <text:list-item>
            <text:p text:style-name="P1">
                bbbbbb<text:change text:change-id="ct242184032"/>cccccc
            </text:p>
            <text:list>
                <text:list-item>
                    <text:list>
                        <text:list-item>
                            <text:p text:style-name="P1">dddddddddddd</text:p>
                        </text:list-item>
                        <text:list-item>
                            <text:p text:style-name="P1">eeeeeeeeeeee</text:p>
                        </text:list-item>
                    </text:list>
                </text:list-item>
                <text:list-item>
                    <text:p text:style-name="P1">ffffffffffff</text:p>
                </text:list-item>
            </text:list>
        </text:list-item>
        <text:list-item>
            <text:p text:style-name="P1">gggggggggggg</text:p>
        </text:list-item>
    </text:list>
</office:text>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]