Generic Change Tracking, example 6.4.2 the latter andcanonicalization of text:style-name

[monkeyiq <monkeyiq@gmail.com>]

Hi,
  While hacking away at abiword and the generic change tracking proposal, I hit upon the example 6.4.2 of the generic spec. I had earmarked this example as one that presented a fair impedance mismatch between the internal abiword tracking data model and the proposed serialization to ODT+GCT. While the delete-leaving-content construct is very powerful, perhaps text:style-name changes are an example use of this GCT construct which is unnecessarily complex. 

  I propose a slightly different serialization for text:style-name at the end of this mail. There are likely some cases which have been considered by the spec makers which will break my serialization for applications treating files as plain ODT? The main downside that I can see with my plan is that applications which do not know about GCT will have to parse and process each nesting text:span/text:style-name for older revisions when loading such a document.

The example 6.4.2 extends an embolding to include an extra word at the start of the block and remove a single word at the end. Using rNo where N is the revision number, and o is the style operation (b=bold,i=italic) one gets the following. Bold and Italic should appear as one would see in revision3 if html email is rendered as expected.

Here is some <r3b>text </r3b><r1b>where the <r2i>decoration</r2i> is <r3n>changed<r3n></r1b> several times.

Note that this means that the word "changed" is now in normal text but was bold in revision 1. The proposal serializes this as the following:

<text:p>
Here is some 
  <text:span delta:insertion-type='insert-around-content' 
             delta:insertion-change-idref='ct2' text:style-name="bold-style">
  text 
  <delta:remove-leaving-content-start delta:removal-change-idref='ct2'
                                      delta:end-element-idref='ee888' />
      <text:span text:style-name="bold-style"/>
  </delta:remove-leaving-content-start>
  where the 
  <text:span delta:insertion-type='insert-around-content' 
             delta:insertion-change-idref='ct1'
             text:style-name="italic-style">
     decoration
  </text:span>
  is 
  </text:span>
  changed
  <delta:remove-leaving-content-end delta:end-element-id='ee888'/>
  several times.
</text:p>

This same example is serialized in abw format by abiword as the following. The <c> tag can be thought of somewhat like ODT text:span. Looking at the second last <c> tag, we can see that abiword explicitly records that the font went to bold in revision 1 and then was changed back to normal in revision 3 (!3 is a change in rev 3).

<c revision="1">Here is some </c>
<c revision="1,!3{font-weight:bold}">text </c>
<c revision="1{font-weight:bold}">where the </c>
<c revision="1{font-weight:bold},!2{font-style:italic}">decoration</c>
<c revision="1{font-weight:bold}"> is </c>
<c revision="1{font-weight:bold},!3{font-weight:normal}">changed</c>
<c revision="1"> several times.</c>

Section 5.1.3 of OpenDocument-v1.2-part1-cd03.pdf (page 117/801) states that text:span may appear within a text:span. Given this nesting possibility, I propose to have abiword create a more direct translation for styles to produce an ODF file like the following. 
<text:p text:style-name="Normal" delta:insertion-change-idref="1" >
Here is some 
<text:span   text:style-name="bold" delta:insertion-change-idref="3" >text </text:span>
<text:span   text:style-name="bold" delta:insertion-change-idref="1" >where the </text:span>
<text:span   text:style-name="bold" delta:insertion-change-idref="1" >
  <text:span text:style-name="boldital" delta:insertion-change-idref="2" >decoration</text:span>
</text:span>
<text:span   text:style-name="bold" delta:insertion-change-idref="1" > is </text:span>
<text:span   text:style-name="bold" delta:insertion-change-idref="1" >
  <text:span text:style-name="norm" delta:insertion-change-idref="3" >changed</text:span> 
</text:span>
several times.
</text:p>

One complexity I see is for a span which had partial formatting revoked. For example, if in revision 4 "decoration" has italic removed then another nested text:span would be needed and have to reference a style as at revision 3 sans the italic though this style work has to be done by abiword internally anyway to be able to show the document at last revision.

1,!2{font-weight:bold},!3{font-style:italic},!4{font-weight:normal}

Thoughts on the text:span nesting idea?