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] Serialization and change tracking


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




 



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