[WebODF] OpSetParagraphStyle and OT

Friedrich W. H. Kossebau friedrich at kogmbh.com
Tue Jun 25 19:26:21 CEST 2013


Hi WebODFler,

currently the spec of OpSetParagraphStyle has a parameter "position" which 
identifies the paragraph to set the style for by being somewhere inside that 
paragraph.

Worked fine so far, but poses a big problem on doing OT versus all kind of 
other operations.

(There is also anothe issue, in that there are the parameters 
"styleNameBefore" and "styleNameAfter", of which only "styleNameAfter" is 
used, and for the other so far no use is seen. So ideally "styleNameBefore" is 
removed and "styleNameAfter" is renamed to just "styleName")

To refresh your memories, this is the background:
Two clients A and B create operations based on the same state of the document, 
which they first apply locally and only then exchange with the other clients. 
The goal is to have the documents at all clients to converge against each 
other in the end, ideally being identical, after all operations have been 
applied at all clients.
So A now gets the operations from B and needs to have them transformed against 
its own locally applied operations, while B gets the ones from A and needs the 
reverse, A's operations being transformed against its own locally applied 
operations.
There are cases where tie-breaking is needed, usually when the same object 
gets modified by the two ops which have to be transformed each other, think of 
two OpUpdateParagraphStyle modifying the same style or two OpInsertText 
targetting at the same position. Here some arbitrary priority is needed, which 
needs to be based on a property which is the same everywhere (e.g. order of 
memberIds or which op is first on the server).
Sometimes longer sequences of ops are transformed against each other. Which 
means that when dealing with the non-first ops these are based on virtual 
states of the documents and thus querying additional properties from the 
document is not possible. Applying the ops to some temp document for that is 
possibly way too expensive (unless we could do some light-weight shadow 
document, but the remove/inserttext ops need the full DOM), especially on 
multi-op transformation lots of documents would need to be created.
(place of the cross-transformation of the ops does not matter for this)


Now here are the samples where things fail ATM (always assuming A's ops have 
priority):
Doc: <text:p>Text</text:p>
A: [<setParagraphStyle pos="0" styleNameAfter="S1" memberId="A"/>]
B: [<setParagraphStyle pos="3" styleNameAfter="S2" memberId="B"/>]
Obviously hard to know if both target the same paragraph.
Proposal: fix by identifying the paragraph with by its first position

Using this proposal, there is another issue:
Doc: <text:p>AB</text:p><text:p>C</text:p><text:p/>
A: [<setParagraphStyle pos="3" styleNameAfter="S1" memberId="A"/>]
B: [<removeText pos="0" length="1" memberId="B"/>]
How can the setParagraphStyle op be transformed against the removeText op, in 
such a way that the pos attribute again points to the begin of the paragraph? 
There is no information in the removeText op which paragraphs are affected and 
how.

So while OT between two OpSetParagraphStyle might be fixable by just using the 
first position in the paragraph as id, this will fail with transformation 
versus OpRemoveText, because its spec addresses the touched objects only 
indirectly and thus cannot provide the needed information to transform 
OpSetParagraphStyle against it.

How to solve that? Naively I would now propose to change the spec of 
OpRemoveText, which has anyway evolved to something that no longer matches its 
name. It would need to change to an op which is as specific as needed in its 
spec so that other ops can transform against it. Which surely is a general 
rule, as I find out by that :)

How a new spec might look like? No real idea yet, but it needs to tell which 
paragraphs and which parts in it are removed. So OpSetParagraphStyle can be 
properly transformed against it.

So no real question here, just loud thinking. Comments welcome.

Cheers
Friedrich
-- 
Friedrich W. H. Kossebau // KO GmbH
http://kogmbh.com/legal/


More information about the WebODF mailing list