Hi Peter, Very good work! There are some cases that should/might be resolved in your list of examples. Identification in the ODF application model and ODF XML is accomplished by their position. The Merge mechanism based on operational transformation (OT) is based upon it. Therefore a second id is redundant and dangerous: (id = generic ID number to identify nodes in the xml) Similar as above the identification is always the position. Some names in-between must be omitted. Let me explain: You and I are working in collaboration on a document with 1 million paragraphs and I am changing the background color of the last paragraph to red. In former times the change was tracked by XML in the content.xml by doing the approach of saving the a before/after status XML . Now it is possible by referencing the position to sent only the change and the position of the 1millon th paragraph. Let me explain OT. I am working on the 3rd Paragraph, but you insert a new 2nd paragraph. I still want to work on the same paragraph, but if we commit your change before mine (similar to doing a commit to a decentralized git repository), I will have to adjust my adoption on the 3rd paragraph to become the fourth. One way to do change-tracking/merging is to think of a list/stack of operation, like a stack of cards. Every time an operation is commited to the document, the operation is placed on top of the others on the top of the card /operation deck. It is like the top is the last and is dependent of the actions of the cards below it. To undo a change, you need to remove a card/operation from the card deck, but only the last (on top) can be surely be removed without harm, as we know that nothing is depending on it. Therefore any other card within the card deck have to be moved to the top. This can be done for instance by changing the position of the card/operation to be removed with its card on top. When doing so, it is like changing the time history. The prior top card, which was executed originally later/after our card we want to move up, is now done prior, when we exchange the cards. But when the upper card is a deletion/insertion of a component, which is before/ahead of the existing (in other words is influencing its position) the position has to be adopted. Example. I change the 3rd paragraph background color to red, afterwards on top is the insertion of a new 2nd paragraph. If we switch those, the top card is now the background color applying to the fourth paragraph. :) Last example: If I sent all collaboration partners an operation telling them that I have inserted the table svante007 they have not the faintest idea, where this table have to placed within our shared document. Right? @5 you added (me=moved end, ms=moved start), how about de & ds for destination or even more verbose wording? @8/9 May I have the example document with the paragraph break? @15 I have to talk to Oliver-Rainer Wittmann, if we can rely on the image name/path (i guess we should). Likely we save the image within the /changes directory to be able to restore it, when necessary. @21 No need for an extra row position parameter, it is just a position similar to a text position. For instance the 2nd row of the a table being the first component would be /1/2 . @23/24 When it comes to columns or cell-ranges, I would suggest to use cell ranges in general. In general I find it handy to use all ODF Table handling by the split into two algorithms. One is taking care of the selection, the other taking care of the adoption/change. The first could be reused and is providing the second each element of the selection. By doing so, I was able to traverse the table only once and avoid a lot of code duplications. Happy Easter! Svante PS: As written on the TC list, I would like to move the discussion on the SC Collaboration list - as this SC was created to separate discussions on this specific functionality from the TC. Still thank you very much for your work. Am 10.04.2014 11:49, schrieb Peter Rakyta: Dear TC members! As you might know, I develop an extension implementing the merge enabled change tracking proposed by Svante. Recently I have made further progress in the development. However I would like to address several questions in order to bring closer the specification and implementation. -- I have uploaded an odt (
https://www.oasis-open.org/committees/document.php?document_id=52714&wg_abbrev=office ) containing the currently supported change types with simple user cases of the related xml tags in the undo.xml. I would like to ask you to revise these tags. Regarding style changes I kept the possibility of representing them explicitly in the xml, since automatic style names are still unreachable through the UNO, and the user-generated styles are not enough to thoroughly track style changes. (In the linked odt both bold/italic textparts correspond to the same text body style.) Hence I suggest to keep this possibility also in the standard. What do you think? -- I think in order to get usable change tracking system, we need also to export data on the author, creation time, and other metadata (like a comment). May be these data should be also a part of the specification to ensure different implementations would handle these data the same way. What do you think? Currently my extension makes revisions of a document, means, that particular OTs (changes) are grouped under changesets (like an SVN). (An example for the XML representation of a changeset is also shown in the linked odt.) Best Regards, Peter --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php