office-collab — archive

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

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