Serialization and change tracking

[Tristan Mitchell <tristan.mitchell@deltaxml.com>]

While looking at the example in the ECT proposal (the one named UC1 in Robin's earlier email) I have spotted a potential problem with different, but semantically equivalent serializations of the document and the way that recorded change transactions can be processed.

The example given is of a paragraph that uses a bold paragraph style. A plain text character style is then applied to one of the words (ct1) followed by an underline character style being applied to part of that same word (ct2). The three versions of the paragraph are:

1) Remove bold

2) Remove bold

3) Remove bold

Assuming that the relevant paragraph and character styles have been defined, the three versions of the paragraph can be represented by:

1)

<text:p text:style-name="BoldStyle">

  Remove bold

</text:p>

2)

<text:p text:style-name="BoldStyle">

  Remove 

  <text:span text:style-name="NormalStyle">bold</text:span>

</text:p>

3)

<text:p text:style-name="BoldStyle">

  Remove 

  <text:span text:style-name="NormalStyle">b</text:span>

  <text:span text:style-name="UnderlinedNormalStyle">ol</text:span>

  <text:span text:style-name="NormalStyle">d</text:span>

</text:p>

The above representation is the cause for the potential problem because the central span mixes the effects of ct1 and ct2 in such a way that it is no longer possible, with either the ECT or GCT representation, to reject ct1 as a standalone operation. A rejection of ct1 should leave the word 'bold' in a bold face with the letters 'ol' underlined.

The ECT representation of change for this paragraph is given as:

<text:p text:style-name="BoldStyle">

  Remove 

  <ct:format-change-start ct:id="1"/>

  <text:span text:style-name="NormalStyle">b</text:span>

  <ct:format-change-end ct:id="1"/>

  <ct:format-change-start ct:id="2"/>

  <text:span text:style-name="UnderlinedNormalStyle">ol</text:span>

  <ct:format-change-end ct:id="2"/>

  <ct:format-change-start ct:id="1"/>

  <text:span text:style-name="NormalStyle">d</text:span>

  <ct:format-change-end ct:id="1"/>

</text:p>

In order to reject ct1, the spans contained immediately within start/end markers for ct1 should be removed (as I understand it) which would leave 'b' and 'd' as bold text but 'ol' would remain as plain underlined text. In fact, with the ECT representation, rejecting ct2 in the same way would leave 'b' and 'd' as plain text but would incorrectly revert 'ol' to bold text at the same time as removing the underline.

The GCT representation is more verbose but still has the same problem that ct1 cannot be rejected on its own. In this case, ct2 can be rejected correctly.

If an alternative representation using nested spans was used, the problem could be avoided:

<text:p text:style-name="BoldStyle">

  Remove 

  <text:span text:style-name="NormalStyle">b<text:span text:style-name="UnderlinedStyle">ol</text:span>d</text:span>

</text:p>

If this representation is used, ct1 can be rejected (by removing the outer span), leaving the 'ol' correctly underlined but bold. This would work correctly in both proposals as far as I can tell.

The three-span representation, which is used by OpenOffice.org at least (I haven't tested other implementations), although visually correct, does not do very well at representing the editing operations that have occurred and so cannot be tracked well (the relationship between change tracking and editing operations has been well-establisehd in previous discussions). We need to consider how to advise implementors of the best way to serialize changes such as these in order to best facilitate change tracking.

--
Tristan Mitchell, DeltaXML Ltd "Change control for XML"
T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK