Tristan:
> I suppose it depends on how the change is made in the first place.
Yes, I think that’s the rub. Off the top of my head, I think it varies based on how the style change is effected in markup – along the lines of, is it specified
as a delta (“add underline to whatever style is there”) or as a fully-specified style (“normal text, underlined”). In the first case, rejecting ct1 reverts the “whatever style is there” and leaves an underline on bold. In the second, rejecting ct1 doesn’t
change the fact that “ol” is “normal text, underlined”. So, as with many things, it looks like application behavior. But since the two approaches above (which I believe are both possible) result in different markup, I think it’s interoperable and not idiosyncratic
to a given app.
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.
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]
Sent: Wednesday, June 22, 2011 7:46 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Serialization and change tracking
UC1
These discussions raise an interesting issue, independent of the representation. Having done some experiments with OOo and Word, it appears that if (in a bold paragraph per UC1) three words are selected and made normal, then the middle one is made underlined,
the changes can be undone in reverse order in the editor session but when saved in OOo or change tracked in Word, the result is three independent format spans. So it is not possible to undo the edits that were actually made.
So it seems that what is actually change tracked in Word (note I do not have the latest version, am using Word:mac 2008) could be represented as this:
<text:p text:style-name="BoldStyle">Remove
<text:span text:style-name="NormalStyle" delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1'>b</text:span>
<text:span text:style-name="UlNormalStyle" delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct2'>ol</text:span>
<text:span text:style-name="NormalStyle" delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1'>d</text:span>
</text:p>
If ct2 is undone, the 'ol' returns to be BoldStyle, which is not strictly correct. On the other hand, because all three spans are 'independent', the formatting on each can be undone independently. This is simpler to represent and arguably simpler for the user
to understand.
A better representation would be the equivalent of the John's ECT representation (the improved one in later email 21/06/2011), and in GCT this is as below, where the formatting of 'ol' reverts more correctly back to NormalStyle if ct2 is undone.
<text:p text:style-name="BoldStyle">Remove
<text:span text:style-name="NormalStyle" delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1'>b</text:span>
<text:span text:style-name="UlNormalStyle" ac:change001="ct2,modify,text:style-name,NormalStyle”
delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1'>ol</text:span>
<text:span text:style-name="NormalStyle" delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1'>d</text:span>
</text:p>
Then as Tristan points out the nested representation is closer to what the user did, as follows in GCT:
<text:p text:style-name="BoldStyle">
Remove
<text:span text:style-name="NormalStyle"
delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1'>b<text:span text:style-name="UnderlinedStyle"
delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct2'>ol</text:span>d</text:span>
</text:p>
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)
What are we aiming for?
On 22/06/2011 11:10, Tristan Mitchell wrote:
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:
.snip
---------------------------------------------------------------------
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
--
-- -----------------------------------------------------------------
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