Svante, Sure, start with:
https://standards.iso.org/ittf/PubliclyAvailableStandards/c071691_ISO_IEC_29500-1_2016.zip (so we are looking at the same file). I had to hunt for the reference, I remembered it clearly but not the section number. This is under shared workbooks but the logic for documents is the same. ***** 18.11.1.16 revisions (Revisions) This element represents the root node of a list of revisions made in this shared workbook. This root node shows up at the beginning of every log file that contains specific revisions made to the workbook. When multiple users are sharing, and editing, a workbook at the same time, there can be conflicting changes. The spreadsheet application should have logic to resolve such conflicts, and the file format should only contain enough information so that the spreadsheet application can restore the workbook to the correct state after conflict resolution. Revisions can also be tracked by the spreadsheet application for review by the user at a later time (as opposed to only dealing with conflicts on a save event.) Some edits to workbooks are made as a result of this conflict resolution. So, there are cases where a revision is effectively undone by another user, and as a result that undoing is itself a revision that adds or changes data in the file. These operations are tracked by the ua and ra attributes of many different elements. ***** Examples follow but I have omitted those. Of course ... the correct state after conflict resolution is being a valid ODF instance. Hope you are having a great evening! Patrick On 9/2/20 3:50 PM, Svante Schubert wrote: Patrick, could you provide us with further information about the separations of concerns by ISO 29500? Do you have a direct reference? Best regards Svante Am Mi., 2. Sept. 2020 um 21:35 Uhr schrieb Patrick Durusau <
patrick@durusau.net >: Greetings! I'm not at all sure we will reach change tracking/collaboration for ODF 1.4 but I have been reading / researching the issues relative to markup and think we can greatly simplify the task before the TC. As you may recall, there were numerous (endless?) discussions of how a new paragraph would change the position of a current paragraph and what happens to edits to the current paragraph and such. I suggest we follow the separation of concerns adopted by our friends over at ISO 29500 and find the reconciliation of collaborative edits occurs ABOVE the level of markup. The only responsibility of markup is to capture the state of RECONCILED edits performed by an application. What is exchanged between applications (one assumes the smallest part possible) nor what applications do internally isn't our issue. All we know is the result passed into markup from the application. Separating that concern out, I suspect but don't know, that specifying change tracking that mirrors or exceeds that in other applications is eminently doable. Not a formal issue, yet, but I wanted to test the waters on the issue of separating concerns. Hope everyone is having a great week! Patrick -- Patrick Durusau
patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog):
http://tm.durusau.net Homepage:
http://www.durusau.net Twitter: patrickDurusau -- Patrick Durusau
patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog):
http://tm.durusau.net Homepage:
http://www.durusau.net Twitter: patrickDurusau Attachment: signature.asc Description: OpenPGP digital signature