Re: [office-collab] Generic Change Tracking, example 6.4.2 thelatter and canonicalization of text:style-name

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

On Sun, 2011-04-10 at 20:55 -0600, monkeyiq wrote:
> 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?
> 

I am getting more and more confused about this generic change tracking
proposal. I believe part of my confusion arises from the fact that
abiword implementation details are mixed with proposed ODF
specification. As far as I am concerned the abiword implementation
details do not matter at all. The real question is whether the proposed
specification allows a consumer to readily reconstruct the changes even
if the file was written by an unknown compliant producer. 

As far as I can tell it would be nearly impossible for an application to
do so. Even something as simple as deleting a column in a spreadsheet
may not be uniquely identifiable, ie. in a spreadsheet with 256 rows and
content in the first 20 rows the deletion of B1:B100 appears to be
recorded in the same way as deletion of B1:B265. 

Andreas 

-- 
Andreas J. Guelzow
Concordia University College of Alberta

This is a digitally signed message part