[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