ODT Track Changes: Is ordering needed for atomic changes?
| Poster | Content | ||
|---|---|---|---|
nk4um Administrator Posts: 35 | Yes, I see where you are going. I think that therefore we may need to allow grouping of Change Transactions (CT) in some way to allow this. I can see the use of this also for global change, or ''change all'', where a user may want to undo all the changes in one go or undo some of them only. If all the atomic changes are grouped as one CT then this may not be possible. A CT Group could then be used for your example, and for the global edit exanple as above, or indeed to group together changes for any reason. I will work on this to find a good way to group CTs to allow these use cases. | ||
nk4um User Posts: 3 | This was what I initially said: In the spec as written, there does not seem to be any restriction placed on the composition of a change transaction. And that therefore there might be a need of change ordering within a transaction. In order to alleviate the ambiguity in my example, you said, "these changes need to be represented as two transactions, not one", which is a restriction on the transaction composition. I might, as an application developer, decide to let my users group changes at will (something I actually am considering implementing at some stage). A user could then decide to group both the changes I described in one "meta change". Reading the spec as it is, the most logical thing to do is assign both atomic change the same transaction id. | ||
nk4um Administrator Posts: 35 | The first example is not ambiguous if it is one transaction. Your description:
should be represented as two transactions not one, then it will ''undo'' correctly. So what you describe would be:
where 1235 is later than 1234. The application needs to record the granularity and order to get the correct effect of undoing an edit. The format is capable (we hope!) of representing whatever happened! | ||
nk4um User Posts: 3 | The first example is ambiguous: - if the original document is <text:p>This is the original paragraph</text:p>, and the user first adds : "This is later inserted. This is the split part", and then splits what he added, and both atomic changes are unified in the same transaction, then the resulting ODF will be what I described. Undoing it like you pointed does not lead to the original document. You are right for the second example, since the span boundaries would include the delete-mixed-content element in case it was not undone first, then the span formatting would apply on reinsertion. | ||
nk4um Administrator Posts: 35 | Pierre, In your first example, the result is unambiguous and will be:
The rule is "Therefore the first part of the split paragraph is the preceding sibling paragraph ignoring any elements that have been added in the same or a later Change Transaction." So there is no doubt that the split para is the first one. So I do not think this example means that we need ordering of atomic changes. For your second example, we start with
and go back to the same thing as both changes are undone. The change is represented as you say. But I cannot see how to get the results you suggest if we reject both changes, perhaps you could explain your reasoning. Perhaps the terms we are using are not clear. A ''change transaction'' is a single change (typically a single editorial action) which is either accepted or rejected. It may consist of one or more ''atomic changes'' - an atomic change is a change that has a single syntactic representation. It may be that we need to have other higher levels of grouping so a user can for example accept or reject each change in a global edit. Let me know if you think we need this extra level of grouping. | ||
nk4um User Posts: 3 | If an insertion of paragraph and a split of paragraph are combined into the same change transaction and the document is saved. We would have: <text:p>This is the original paragraph.</text:p> <text:p delta:insertion-type="insert-with-content" delta:insertion-change-idref="1234">This is later inserted.</text:p> <text:p delta:insertion-type="split" delta:insertion-change-idref="1234">This is the split part</text:p> An application loads this file. On undoing this change transaction: - if first the split is undone the document becomes: <text:p>This is the original paragraph.</text:p> <text:p delta:insertion-type="insert-with-content" delta:insertion-change-idref="1234">This is later inserted.This is the split part</text:p>. Then after undoing the "insert-with-content", the document becomes: <text:p>This is the original paragraph</text:p> - if first the "insert-with-content" is undone, the document becomes: <text:p>This is the original paragraph.</text:p> <text:p delta:insertion-type="split" delta:insertion-change-idref="1234">This is the split part</text:p> Then after the "split" operation is undone, the document becomes: <text:p>This is the original paragraph.This is the split part</text:p> Another example: if both an unformating and a deletion is combined: <text:p>This is original <text:span delta:removal-type=''remove-leaving-content'' delta:removal-change-idref=''345'' text:style-name="bold-style" delta:end-element-idref=''888''/>bold <delta:deleted-mixed-content delta:removal-change-idref=�345�>deleted</delta:deleted-mixed-content><end-element delta:end-element-id=''888''/> If the deleted text is first undone and then the unbold, we will finish with: This is original bold deleted If first the unbold and then the delete is undone, we will finish with: This is original bold deleted I am sure there could be other examples. Which means there should either be ordering of atomic changes or strict rules of what can be combined into a transaction | ||
nk4um Administrator Posts: 35 | Pierre Stirnweiss:
Robin La Fontaine: There is no ordering of atomic changes within a change transaction because the changed transaction is viewed as a single transaction/event. It is not clear why we would need an ordering, or what it would mean. I cannot see a use case for this. |
Released under the MIT License
