Re: [office-collab] Serialization and change tracking

[monkeyiq <monkeyiq@gmail.com>]

On Fri, 2011-06-24 at 11:02 +0100, Robin LaFontaine wrote:

John:
Thanks for your comments, it does make sense to allow arbitrary ordered rejection, though it is a bit of a challenge. Although the nested span solution does work for the simple example we have here, it does not scale to more complex situations. I have been trying to work out if there is a way round this. I think that there may be if we can make two rules as follows:

1. Spans cannot be nested.

2. Two consecutive spans that have exactly the same attributes is semantically equivalent to a single span with those attributes.

(There is also the rule that a span with no attributes is semantically equivalent to no span... but I think that is the case now.)

This allows us to change the start position, which I think is the key to allowing a scalable solution. Currently, we have a start position as follows:

<text:p text:style-name="BoldStyle">Remove bold</text:p>

However, if we can change this to  a start position like this:

<text:p text:style-name="BoldStyle">Remove
    <text:span>b</text:span>
    <text:span>ol</text:span>
    <text:span>d</text:span>
</text:p>

Then our problem is reduced to simply specifying a history of attributes on these spans. Therefore the solution would look something like this in GCT (you will do a better job of the equivalent ECT than I can):

<text:p text:style-name="BoldStyle">Remove
    <text:span text:style-name="NormalStyle"  ac:change001="ct1,add,text:style-name">b</text:span>
    <text:span text:style-name="UlNormalStyle"   ac:change001="ct1,add,text:style-name"
    ac:change002="ct2,modify,text:style-name,NormalStyle">ol</text:span>
    <text:span text:style-name="NormalStyle" ac:change001="ct1,add,text:style-name">d</text:span>
</text:p>

This solution can be scaled up to any arbitrary changes of text formatting for any combination of character sequences. It also allows rejection in an arbitrary order, although some calculations would have to be done to effect this.

FWIW this is fairly much the serialization I arrived at for abiword. Though I arrived at this serialization with the help of Frank Meies when trying to code example 6.4.2 from the GCT [2].

A slightly cleaned up version of the ODT that abiword [1] currently produces for the changes is below. The edits to produce this were as follows. Note that I have changed the style-name strings in order to give their meanings implicitly.

Edits:

id=1, Remove Bold
id=2, Remove Bold
id=3, Remove Bold


ODT Fragment:

<text:p text:style-name="Normal" delta:insertion-type="insert-with-content" delta:insertion-change-idref="1" >
    <text:span text:style-name="bold" delta:insertion-change-idref="1">Remove </text:span>
    <text:span text:style-name="norm" delta:insertion-change-idref="2" 
               ac:change3="1,insert,text:style-name," 
               ac:change4="2,modify,text:style-name,bold">B</text:span>
    <text:span text:style-name="normUL" delta:insertion-change-idref="3" 
               ac:change4="1,insert,text:style-name," 
               ac:change5="2,modify,text:style-name,bold" 
               ac:change6="3,modify,text:style-name,norm">ol</text:span>
    <text:span text:style-name="norm" delta:insertion-change-idref="2" 
               ac:change3="1,insert,text:style-name," 
               ac:change4="2,modify,text:style-name,bold">d</text:span>
</text:p>

change-id=3 is simple to undo here. To undo a change that is midway through an ac:change set is a little more complex as you have to shuffle its attribute value down in the ac:change list.

To illustrate, assume the following change-id=N, edited text sequence:

id=1, foo
id=2, foo
id=3, foo
id=6, foo

This should give a text:span with these GCT attributes:

text:style-name="underlined"
ac:change4="1,insert,text:style-name," 
ac:change5="2,modify,text:style-name,bold" 
ac:change6="3,modify,text:style-name,norm"
ac:change7="6,modify,text:style-name,ital"

To revert id=3 the edit sequence then changes to the following:

id=1, foo
id=2, foo
id=3, foo
id=6, foo

The ODT attributes will have the ac:change6 removed, but its attribute value will have to replace that of the subsequent ac:change, giving the edits:

text:style-name="underlined"
ac:change4="1,insert,text:style-name," 
ac:change5="2,modify,text:style-name,bold" 
ac:change6="3,modify,text:style-name,norm"
ac:change7="6,modify,text:style-name,ital norm"

The of course avoids the sticky situation where one might want to apply change tracking to the reversion of a change.


[1] https://github.com/monkeyiq/odf-2011-track-changes-git-svn
[2] http://lists.oasis-open.org/archives/office-collab/201104/msg00046.html

Robin


On 22/06/2011 18:59, John Haug wrote:

Robin:

So, this raises the question of what we are trying to represent in the CT format:
1. the representation of the changes in the internal data structure of an editing application or
2. an enhanced version of this representation which allows reverse-order undo
3. something closer to the actions of the user making the edit, which in this example could be undone in any order (though probably not in more complex cases)



From my/our perspective, I think we’ve noted before that we feel arbitrary-order rejection is important.  I think this is the dominant user mode as documents are created, edited, passed around, edited more, etc.  That said, there seems to be a tradition among some ODF implementations of maintaining a clear notion of order of changes, at least for presentation to the user even though they seem to support both ordered and arbitrary rejection.  I’ve mentioned elsewhere that I think it’s important to be closer to what users are doing so that those usage scenarios are supportable by the file format.  As long as the format supports data storage for an implementation to interpret it within whatever scope of features it chooses to support, we’re in good shape.  I think that still leads us closer to 3 than 1 without disallowing 2’s reverse-order handling.

 

 

..snip

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php