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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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


Subject: Re: [office-collab] Generic Change Tracking, example 6.4.2 the latterand canonicalization of text:style-name


Hi all,

I agree that the remove-leaving-content might add unnecessary complexity. But often this can be avoided by splitting your text portions: In OOo Writer, I guess the example would be coded this way:
<text:p>
  Here is some 
  <text:span delta:insertion-type='insert-around-content' 
             delta:insertion-change-idref='ct2'
             text:style-name="bold-style">
     text
  </text:span>
  <text:span text:style-name="bold-style">
  where the
  </text:span>
  <text:span text:style-name="bold-italic-style" ac:change001="ct1,change,text:style-name,bold-style">
     decoration
  </text:span>
  <text:span text:style-name="bold-style">
  is
  </text:span>
  <text:span text:style-name="normal" ac:change002="ct2,change,text:style-name,bold-style">
  changed
  </text:span>
</text:p>

However, if you completely want to reset the formatting of the word "changed" instead of setting the style to "normal", you either have to use remove-leaving-content or you have to remove the respective span and insert the text content behind the span.

Regards,

Frank

On 11.04.2011 04:55, monkeyiq wrote:

1302490527.1516.42.camel@alkid.localdomain" type="cite"> 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?


--
Oracle
Frank Meies | Software Developer
Phone: +49 49 23646 500
Oracle OFFICE GBU

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg


ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green
          Oracle Oracle is committed to developing practices and products that help protect the environment


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