Pierre Stirnweiss:
- one thing struck me as a major flaw. For the split change, the spec seems
to make an implicit link between the new split element and its previous
sibling. It also assumes that all elements between the two part of the
splits are added by the same CT or further CTs. I think this is extremely
dangerous. Specially when considering the second use case I was referring
to. Consider the following:

Initial state:
This is a paragraph that will be split in two. The split occurred before
this.

User A, enabling change tracking, press carriage return between the two
sentences. The document will be saved as:
<text:p>This is a paragraph that will be split in two.</text:p>
<text:p delta:insertion-type=''split'' delta:insertion-idref=''1''>The split
occurred before this.</text:p>


So far so good. Now the document is given to user B, who uses an
application which do not understand change tracking, or has change
tracking disabled. He wants to add a paragraph between the two lines:
This is a paragraph that will be split in two.
This is an untracked paragraph added by User B.
The split occurred before this.

The saved document corresponding to this will be:
<text:p>This is a paragraph that will be split in two.</text:p>
<text:p>This is an untracked paragraph added by User B.</text:p>
<text:p delta:insertion-type=''split'' delta:insertion-idref=''1''>The split
occurred before this.</text:p>


Now the split does not refer to the original split but to a split which
would have happened between the paragraph added by user B and the original
second sentence. The original User A intention is not preserved, which is
wrong.

I think both sides of the split should keep a link to each other, so
original intention is preserved in all cases. I tend to dislike systems
designed with assumptions or implicit relations between several of its
components because they usually are fragile.


Robin La Fontaine:
This is a very useful comment. I think there are two points that come out from this, the first being that there is no explicit link between the two parts of the split. The second point is that recorded changes may be interrupted by changes that are not recorded, and this is a requirement which we had not considered.


Regarding the first point,  at first sight it appears that it would be clearer if the two parts of the split where explicitly linked. However doing this is not trivial, because a paragraph may be split several times and therefore may potentially be the start paragraph of several splits.  In order to achieve this, we would need to introduce a new attribute namespace and have generated attribute names, in a manner similar to the handling of attribute changes.

It is worth thinking a little bit more about why we would want this link. In the example you have given, if we have the link then we would know that this particular split cannot be undone because of the intermediate paragraph.  Or, if it can be undone, then we need to define what the result would be because it is not obvious whether the second half of the paragraph moves up to be with the first half or vice versa.  The only unambiguous way to represent this would be with a move.

On the other hand, we could argue that undoing this split would simply merge it with the previous paragraph. Although this is not undoing the original operation, it is arguably as good an interpretation as the previous ones.  In this case of course we do not need to know which paragraph was the first part of the split originally.

I am coming to the conclusion that your example does not so much demonstrate the need to link the two parts of a split, as the need to represent your example in a different way!


Regarding your second point, I think it will be possible to think up a scenario where a change that has not been tracked has the effect that a tracked change can no longer be undone. Given our definition of the correctness of a tracked changed, this would mean that the tracked change was no longer correct. Arguably, this would be for a software application to sort out when it writes out the data. Only the software application has knowledge of the order of the changes and whether or not they are tracked, and therefore it would need to sort out the situation in order to ensure that all the tracked changes that are written out are correct, i.e. the state of the document before the tracked change is valid and the state of the document after the tracked change is valid.