[WebODF] OpSetParagraphStyle and OT

[Friedrich W. H. Kossebau]

Am Mittwoch, 26. Juni 2013, 19:58:27 schrieben Sie:
> On 26 June 2013 03:26, Friedrich W. H. Kossebau <friedrich at kogmbh.com>wrote:
> > 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.

> The desired intent is that each client end up with the same document, 
> though the ops
> are processed in a different order right.

Right.

> Consider the following scenario:
> <text:p>P1</text:p>
> 
> A: [<setParagraphStyle pos="P1 start" ...>]
> B: [<splitParagraph pos="P1 start" ...>]
> 
> Client A processes A then B, and ends up with the style applied to both
> paragraphs (this is the intended result).
> Client B splits first, then needs to realise that the style should be
> applied to the new paragraph as well.

Yes, another nice example where just the (starting) position of the paragraph 
with setParagraphStyle op would not work in OT.

> If setParagraphStyle carries both the start and end of the paragraph
> positions, it would be trivial
> to tell where the old styled paragraph ended. Every paragraph up to this
> point is expected to carry the
> new style. For the above example, client B would perform the following
> 
> 1. Apply splitParagraph at position 1 (just after the 'P'). This inserts a
> new cursor position.
> 2. Transform setParagraphStyle end pos (or length) by +1
> 3. setParagraphStyle fetches all paragraphs in the specified range and
> applies the style to these
> 
> Is there a glaring hole in that approach?

That basic approach should be fine, yes.
Just that instead of 3) there would be instead another setParagraphStyle op 
created, which sets the given style for the second of the split paragraphs. 
This would then result in no further troubles if e.g. B not only has 
<splitParagraph pos="P1 start" ...> but also another setParagraphStyle op 
locally applied which sets the style to one of the two paragraphs, which 
should also still be present in the final document:

<text:p>P1</text:p>

A: [<setParagraphStyle pos="P1 start" style="X"...>]
B: [<splitParagraph pos="P1 start" ...>
    <setParagraphStyle pos="P1 start"  style="Y"...>]

So B not only splits the paragraph, but sets a style to the first of the 
resulting paragraphs.
If B now transforms the op from A against its own apps, it would first 
transform it against the splitting op like before, and then transform the 
result of that against its setParagraphStyle op.
<setParagraphStyle pos="P1 start"  style="X"...>
<setParagraphStyle pos="P1 start + 1"  style="X"...>
vs. 
<setParagraphStyle pos="P1 start"  style="Y"...>
where the first would get some tie-breaking due to being both operating on the 
same object (in this case assume B's ops have priority, to see something), and 
the effect of second op would just do what is expected.

Adding additional ops on transformation as needed is done in other places (and 
in other projects) as well, so that is fine.

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