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.
Robin
On 22/06/2011 18:59, John Haug wrote:
91C4760493E4094B9871E5A496374DA232198CB3@DF-M14-01.exchange.corp.microsoft.com"
type="cite">
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
|