Re: [office-collab] Serialization and change tracking

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

John,

Apologies, I had not picked up on the cached previous style state in the example and so yes, as you say, there are no issues with rejecting ct2 with the ECT example.

I'm not sure I agree with you on what style the 'ol' should be in after rejecting just ct1. I suppose it depends on how the change is made in the first place.
The starting state of the text is that it inherits the bold paragraph style.
There is more than one way to (sensibly) get to the final stage:

1) If you select the word 'bold' and press the bold button or Ctrl-B (or whatever your favourite interface does to toggle bold) you have completed ct1. The next step is to highlight 'ol' and press the underline button, or Ctrl-U. This is ct2. In this case, I think that a rejection of ct1 should leave the whole of the word 'bold' as bold text with the 'ol' underlined.

2) Rather than using the buttons or key shortcuts, you could set up character styles. If style A specifies non-bold text and is applied to the whole of the word 'bold', this is ct1. Another style specifies non-bold text (arguably unnecessarily) and underlining and is applied to 'ol' This is ct2. In this case I agree that a rejection of ct1 should leave 'b' and 'd' as bold with 'ol' being non-bold underlined.

The problem then becomes one of storing these subtly different changes in such a way that the rejection of ct1 gives a different result in each case. Performing the two different sets of actions above in OpenOffice.org does not give different results (other than that in 1. the styles are automatic styles and in 2. they are defined in the styles.xml file). I would have have expected action set 1 to produce nested spans but it produces three sibling spans as in the example given in the the ECT proposal.

On 21 Jun 2011, at 19:58, John Haug wrote:

> Unless I’m missing something, I see no issues with the cases you mention…
>  
> The example given in the document should indicate ct2 can be rejected properly.  Remember that the previous format state of the ct2 text is cached in the text:tracked-changes section.  From the example markup:
>  
>    <text:changed-region text:id="2">
>        <text:format-change>
>           <office:change-info> … </office:change-info>
>           <text:span text:style-name="NormalStyle"/>
>        </text:format-change>
>    </text:changed-region>
> 
> This stores the NormalStyle applied to “ol” prior to underlining it, so an application properly rejecting/reverting the change should restore the NormalStyle.  In the same way than the app must split the single pair of ct1 change marks (around “bold”) into two pairs (one each for “b” and “d”) when ct2 is made, an application might recognize that after rejecting ct2 it has 3 adjacent spans of NormalStyle and choose to combine them back down to a single span.*
>  
> As for rejecting ct1 without rejecting ct2, I see two possibilities for runtime behavior:
> 1 – Changes can be rejected in arbitrary order.  Rejecting ct1 correctly leaves “ol” as non-bold underlined text as ct2 has not been rejected.
> 2 – Changes are rejected as a stack.  Rejecting ct1 means the application must unroll the stack and reject ct2 first.  As described above, rejecting ct2 brings “ol” back to NormalStyle and rejecting ct1 brings it all back to BoldStyle via merging the ct1 change marks.
>  
>  
> * There is a complication I see for ensuring the markup makes clear to applications whether to merge, but it appears to be a minor implementation challenge that is solvable within the provisions of the file format we’re discussing.  I’ll touch on that next.
>  
> John
>  
> From: Tristan Mitchell [mailto:tristan.mitchell@deltaxml.com] 
> Sent: Tuesday, June 21, 2011 9:11 AM
> To: office-collab@lists.oasis-open.org
> Subject: [office-collab] Serialization and change tracking
>  
> 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
> 
> 
> 
> 
> 
>  

--
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