OpenDocument - Adv Document Collab SC

Greetings! Sorry 'bout missing a post for yesterday on change tracking! In the ECT proposal, there was a separate treatment of multiple changes to the same content. I don't have the answer but let me sketch the bramble I find myself in: First, if there are multiple changes to a particular piece of text, is there a presumption of fixing of state? That is if I take text from just plain text to *bold text*, save the text and then later come back to that *bold text* and underline the "text" portion of it, there are clearly two change operations to be tracked. If I don't save the text, but simply change it to bold and before saving, also underline the "text" part, is that to be two change operations or only one? That is at what time does the state of the text become "fixed" so that change tracking is engaged again? I know I have inserted text and then changed the inserted text, with nary a trace of the original inserted text. I suspect there is some common rule that implementers apply but I have no idea what it would be. Suggestions? Hope everyone is having a great week! Patrick -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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

Hi Patrick, On 19.09.2012 02:39, Patrick Durusau wrote: > Greetings! > > Sorry 'bout missing a post for yesterday on change tracking! > > In the ECT proposal, there was a separate treatment of multiple > changes to the same content. > > I don't have the answer but let me sketch the bramble I find myself in: > > First, if there are multiple changes to a particular piece of text, is > there a presumption of fixing of state? In MCT there has no state to be fixed. A stack of operations will be applied sequentially to the document, every operation is working on the document state provided by the previous operation. > > That is if I take text from just plain text to *bold text*, save the > text and then later come back to that *bold text* and underline the > "text" portion of it, there are clearly two change operations to be > tracked. Correct. > > If I don't save the text, but simply change it to bold and before > saving, also underline the "text" part, is that to be two change > operations or only one? > Certainly changes will be tracked continuously and saving just does the serialization. > That is at what time does the state of the text become "fixed" so that > change tracking is engaged again? With "fixed" you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. Similar if you add a single character at a time, there can be an operation for each character, but the application might as well compress/condense it to a single operation. As long both operations have the same info set. > > I know I have inserted text and then changed the inserted text, with > nary a trace of the original inserted text. > > I suspect there is some common rule that implementers apply but I have > no idea what it would be. > > Suggestions? > Does the above answer your question? The given scenario seems to be a variation from the earlier given scenario: https://lists.oasis-open.org/archives/office-collab/201206/msg00000.html Solutions: https://lists.oasis-open.org/archives/office-collab/201206/msg00007.html https://lists.oasis-open.org/archives/office-collab/201207/msg00000.html > Hope everyone is having a great week! > > Patrick > Hope you have a great day! Svante

Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become "fixed" so that change tracking is engaged again? With "fixed" you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Which is one presumption but perhaps not the one that the TC desires to make. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text). And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Not objecting to your answer but it leaves out a lot of detail. ;-) Hope you are having a great day! Patrick -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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

Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: > Svante, > > > On 09/19/2012 08:35 AM, Svante Schubert wrote: >> Hi Patrick, > > <snip> >> That is at what time does the state of the text become "fixed" so that >> change tracking is engaged again? >> With "fixed" you might as well think about a compression/condensation of >> operations. For example, if someone inserts a word and deletes it again, >> it will not occur in the CT, although there had been two operations. > That was my question. > > You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). > > Which is one presumption but perhaps not the one that the TC desires > to make. The TC is likely to favor the easiest and efficient model being offered. > > Can think of compression/condensation of operations but that means the > CT syntax has to record multiple changes, say make bold and italic > instead of separate operations of bold, then italic (on the same text). From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by "style blends" from the application vendors. For instance, the "heading 1" style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. > > And, it means we have to define when compression/condensation occurs > and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). > > Not objecting to your answer but it leaves out a lot of detail. ;-) > Sure, just wanted to keep the mail short ;) > Hope you are having a great day! > > Patrick > Hope you are having a great day as well! Svante

Svante, Just quickly. You need to stop eliding over what you mean by "change." From below: Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Now you imply that a change is not a change unless the "create/delete operation ... influence[s} the position of the ...the position integer." Which negates the idea of tracking changes to page formatting (which we track now), changes styles applied to text (a requested feature), none of which impact the position integer. For that matter, it includes changes made as I insert "new" text because the end position pointer is expanding as I type and decreases if I delete part of the inserted text, before some designation of "state." When does the insertion/deletion of *new* text become fixed with regard to OT change tracking? When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Changing the position pointer (start or end) may be part of a definition of change but it is a fairly crude one. Hope you are having a great day! Patrick On 09/20/2012 05:49 AM, Svante Schubert wrote: Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become "fixed" so that change tracking is engaged again? With "fixed" you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Which is one presumption but perhaps not the one that the TC desires to make. The TC is likely to favor the easiest and efficient model being offered. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text). From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by "style blends" from the application vendors. For instance, the "heading 1" style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). Not objecting to your answer but it leaves out a lot of detail. ;-) Sure, just wanted to keep the mail short ;) Hope you are having a great day! Patrick Hope you are having a great day as well! Svante --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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

Hi Patrick, On 20.09.2012 14:07, Patrick Durusau wrote: Svante, Just quickly. You need to stop eliding over what you mean by change. Every operation on the document results into a change of state. Each (stored) operation reflect a change. From below: Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Now you imply that a change is not a change unless the create/delete operation ... influence[s} the position of the ...the position integer. I was former talking about multiple operations, which can be seen as change of a previous change and latter I had been talking how to rearrange changes (operations) in the queue of operations (your quote above). Which negates the idea of tracking changes to page formatting (which we track now), changes styles applied to text (a requested feature), none of which impact the position integer. For that matter, it includes changes made as I insert new text because the end position pointer is expanding as I type and decreases if I delete part of the inserted text, before some designation of state. When does the insertion/deletion of *new* text become fixed with regard to OT change tracking? I am not certain, if I understand the question, but it seems you are puzzling, when an operation should be created by the application, when a user edits a document in its front-end. (see answer below) When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. For instance, instead of three operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 The application might as well sent one operation: insert abc in paragraph 1 at position 1 AFAIK Google Docs is pushing every change right away to the server, like editing in a field using AJAX. Changing the position pointer (start or end) may be part of a definition of change but it is a fairly crude one. Only if the position pointer is part of the document state to be changes, AFAIK OOo is saving it into the settings.xml properties. Otherwise I refer to the beginning of this mail, a change is reflected by an operation call upon the document. Hope you are having a great day! Patrick Hope you are having a great day as well! Svante On 09/20/2012 05:49 AM, Svante Schubert wrote: Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become fixed so that change tracking is engaged again? With fixed you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Which is one presumption but perhaps not the one that the TC desires to make. The TC is likely to favor the easiest and efficient model being offered. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text).  From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by style blends from the application vendors. For instance, the heading 1 style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). Not objecting to your answer but it leaves out a lot of detail. ;-) Sure, just wanted to keep the mail short ;) Hope you are having a great day! Patrick Hope you are having a great day as well! Svante --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org

Svante, On 09/20/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. For instance, instead of three operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 The application might as well sent one operation: insert abc in paragraph 1 at position 1 AFAIK Google Docs is pushing every change right away to the server, like editing in a field using AJAX. We should care because we are *not* writing a protocol for interchange of change tracking information. We are writing a format to track changes in a file format for reading and presentation to a user (same or another user), post change. On the same or a different application. What is meant by: ..resulting in the end of an equal change? I perform the following operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 I move off that changed text and perform changes elsewhere. I return to the abc text, which shows change in my interface and: 4. delete c in paragraph 1 at position 3 Question: Is that reflected in the *markup syntax* that is saved as part of the document? Here is what I get with the latest version of OpenOffice: <text:change-start text:change-id= ct139634698526728 />ab<text:change-end text:change-id= ct139634698526728 /> The rest of the changes tracking: def in paragraph 2 at positions 1, 2, 3 ghi in paragraph 3 at positions 1, 2, 3 I conclude that changes to changes are not tracked in OpenOffice. That could be a *serious* failing if we are tracking changes by authors and a subsequent author can change my change and it still shows up as my change, albeit not as I changed it. Hope you are having a great day! Patrick Changing the position pointer (start or end) may be part of a definition of change but it is a fairly crude one. Only if the position pointer is part of the document state to be changes, AFAIK OOo is saving it into the settings.xml properties. Otherwise I refer to the beginning of this mail, a change is reflected by an operation call upon the document. Hope you are having a great day! Patrick Hope you are having a great day as well! Svante On 09/20/2012 05:49 AM, Svante Schubert wrote: Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become fixed so that change tracking is engaged again? With fixed you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Which is one presumption but perhaps not the one that the TC desires to make. The TC is likely to favor the easiest and efficient model being offered. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text).  From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by style blends from the application vendors. For instance, the heading 1 style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). Not objecting to your answer but it leaves out a lot of detail. ;-) Sure, just wanted to keep the mail short ;) Hope you are having a great day! Patrick Hope you are having a great day as well! Svante --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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

I think there are interoperability and usability issues around how much change is one change, even when made by a single person in a single session in a contiguous part of the document. It has to do with ability to subsequently approve or reject changes. So, while what an implementation does for equivalent changes is certainly up to the implementation, there are consequences, in interchange and in subsequent revision and review work, even by the same author. There are also (limited) consequences in how changes are annotated and identified in terms of author, date-time, and any commentary. These may not be significant, but they do need to be taken into consideration to ensure that it is indeed a benign matter of implementation choice. ODF is a specification for the interoperable use of documents. The change-tracking feature cannot escape that. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Thursday, September 20, 2012 06:26 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Multiple changes Svante, On 09/20/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. For instance, instead of three operations: 1. insert "a" in paragraph 1 at position 1 2. insert "b" in paragraph 1 at position 2 3. insert "c" in paragraph 1 at position 3 The application might as well sent one operation: 1. insert "abc" in paragraph 1 at position 1 [ ... ]

Hi Dennis, On 20.09.2012 18:53, Dennis E. Hamilton wrote: > I think there are interoperability and usability issues around how much change is one change, even when made by a single person in a single session in a contiguous part of the document. Could you give an example? All changes are represented by operations, each operations is defined by an ODF XML change. I can not see the problem scenario you draft. > > It has to do with ability to subsequently approve or reject changes. So, while what an implementation does for equivalent changes is certainly up to the implementation, there are consequences, in interchange and in subsequent revision and review work, even by the same author. There are also (limited) consequences in how changes are annotated and identified in terms of author, date-time, and any commentary. Rejecting a change is similar to taking out an operation out of the operation stack. No side affects, no harms. A reject goes like this: The operation (or set of operations) to be rejected are being moved to the top of the stack (to apply OT to their positions), than removed. > > These may not be significant, but they do need to be taken into consideration to ensure that it is indeed a benign matter of implementation choice. > > ODF is a specification for the interoperable use of documents. The change-tracking feature cannot escape that. No problem AFAIK. Best regards, Svante > > - Dennis > >
Original Message----- > From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau > Sent: Thursday, September 20, 2012 06:26 > To: office-collab@lists.oasis-open.org > Subject: Re: [office-collab] Multiple changes > > Svante, > > > On 09/20/2012 08:35 AM, Svante Schubert wrote: > > > Hi Patrick, > > > <snip> > > > > When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? > > > Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. > For instance, instead of three operations: > > > 1. insert "a" in paragraph 1 at position 1 > 2. insert "b" in paragraph 1 at position 2 > > 3. insert "c" in paragraph 1 at position 3 > > The application might as well sent one operation: > > 1. insert "abc" in paragraph 1 at position 1 > > [ ... ] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: office-collab-help@lists.oasis-open.org >

On Thu, 2012-09-20 at 10:53 -0600, Dennis E. Hamilton wrote: > I think there are interoperability and usability issues around how much change is one change. ODF specifies a file format. It does not specify implementation user interface interaction. I can easily imagine an implementation that allows for a large number changes caused by a single user interaction (delete the content of all dependent) where another implementation would require a user to do this in many steps. If we want to record this in the change tracking info then I would not expect that ther is a single "change" record for this even if the first implementation will present this to its user as a single change. Andreas -- Andreas J. Guelzow, PhD FTICA Professor of Mathematical & Computing Sciences Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

On 20.09.2012 15:26, Patrick Durusau wrote: Svante, On 09/20/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. For instance, instead of three operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 The application might as well sent one operation: insert abc in paragraph 1 at position 1 AFAIK Google Docs is pushing every change right away to the server, like editing in a field using AJAX. We should care because we are *not* writing a protocol for interchange of change tracking information. I suggest we do not invest too much energies to focus on what we should *not* do, who has a benefit from that attitude? Focus on what we are able to archive for our goal of change-racking. To allow an ODF application to undo changes made by another ODF application has much to do of of the interchange of change information. But perhaps we are just again at cross-purposes.. We are writing a format to track changes in a file format for reading and presentation to a user (same or another user), post change. On the same or a different application. What is meant by: ..resulting in the end of an equal change? That the state of the document is the same. I perform the following operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 I move off that changed text and perform changes elsewhere. I return to the abc text, which shows change in my interface and: 4. delete c in paragraph 1 at position 3 Question: Is that reflected in the *markup syntax* that is saved as part of the document? Not being saved. I can rewrite a sentence a dozen times , in the end it is only saved the delta from the start and the end of the session. In other words the operations are being compressed to express the information set representing the session delta. Here is what I get with the latest version of OpenOffice: <text:change-start text:change-id= ct139634698526728 />ab<text:change-end text:change-id= ct139634698526728 /> The rest of the changes tracking: def in paragraph 2 at positions 1, 2, 3 ghi in paragraph 3 at positions 1, 2, 3 I conclude that changes to changes are not tracked in OpenOffice. Sure. That could be a *serious* failing if we are tracking changes by authors and a subsequent author can change my change and it still shows up as my change, albeit not as I changed it. No problem as far as I see... Hope you are having a great day! Same to you, Svante Patrick Changing the position pointer (start or end) may be part of a definition of change but it is a fairly crude one. Only if the position pointer is part of the document state to be changes, AFAIK OOo is saving it into the settings.xml properties. Otherwise I refer to the beginning of this mail, a change is reflected by an operation call upon the document. Hope you are having a great day! Patrick Hope you are having a great day as well! Svante On 09/20/2012 05:49 AM, Svante Schubert wrote: Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become fixed so that change tracking is engaged again? With fixed you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Which is one presumption but perhaps not the one that the TC desires to make. The TC is likely to favor the easiest and efficient model being offered. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text).  From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by style blends from the application vendors. For instance, the heading 1 style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). Not objecting to your answer but it leaves out a lot of detail. ;-) Sure, just wanted to keep the mail short ;) Hope you are having a great day! Patrick Hope you are having a great day as well! Svante --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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

Svante, OK, trying again: When you say: Not being saved. I can rewrite a sentence a dozen times , in the end it is only saved the delta from the start and the end of the session. In other words the operations are being compressed to express the information set representing the session delta. What is a session? If I save my document with tracking on and change a change (deleting the b character) that was tracked, without accepting the changes: <text:change-start text:change-id= ct139634698526728 />a<text:change-end text:change-id= ct139634698526728 /> Previously, before the save, this read: <text:change-start text:change-id= ct139634698526728 />ab<text:change-end text:change-id= ct139634698526728 /> Now I save and *close* the file, is that a session? <text:change-start text:change-id= ct139634712754456 />a<text:change-end text:change-id= ct139634712754456 /> IDs get changed on reload, but changing a change, is still not captured, after save and close of file. So far, at least in the OpenOffice implementation: 1) save does not end a session 2) save and closing document does not end a session 3) ending change tracking does not end a session Of course, OpenOffice does not implement to be specified operations based CT but that means we have to define what is meant by session. I remain convinced this is possible or I would not be pushing so hard on it. Hope you are having a great day! Patrick On 09/20/2012 03:57 PM, Svante Schubert wrote: On 20.09.2012 15:26, Patrick Durusau wrote: Svante, On 09/20/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. For instance, instead of three operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 The application might as well sent one operation: insert abc in paragraph 1 at position 1 AFAIK Google Docs is pushing every change right away to the server, like editing in a field using AJAX. We should care because we are *not* writing a protocol for interchange of change tracking information. I suggest we do not invest too much energies to focus on what we should *not* do, who has a benefit from that attitude? Focus on what we are able to archive for our goal of change-racking. To allow an ODF application to undo changes made by another ODF application has much to do of of the interchange of change information. But perhaps we are just again at cross-purposes.. We are writing a format to track changes in a file format for reading and presentation to a user (same or another user), post change. On the same or a different application. What is meant by: ..resulting in the end of an equal change? That the state of the document is the same. I perform the following operations: insert a in paragraph 1 at position 1 insert b in paragraph 1 at position 2 insert c in paragraph 1 at position 3 I move off that changed text and perform changes elsewhere. I return to the abc text, which shows change in my interface and: 4. delete c in paragraph 1 at position 3 Question: Is that reflected in the *markup syntax* that is saved as part of the document? Not being saved. I can rewrite a sentence a dozen times , in the end it is only saved the delta from the start and the end of the session. In other words the operations are being compressed to express the information set representing the session delta. Here is what I get with the latest version of OpenOffice: <text:change-start text:change-id= ct139634698526728 />ab<text:change-end text:change-id= ct139634698526728 /> The rest of the changes tracking: def in paragraph 2 at positions 1, 2, 3 ghi in paragraph 3 at positions 1, 2, 3 I conclude that changes to changes are not tracked in OpenOffice. Sure. That could be a *serious* failing if we are tracking changes by authors and a subsequent author can change my change and it still shows up as my change, albeit not as I changed it. No problem as far as I see... Hope you are having a great day! Same to you, Svante Patrick Changing the position pointer (start or end) may be part of a definition of change but it is a fairly crude one. Only if the position pointer is part of the document state to be changes, AFAIK OOo is saving it into the settings.xml properties. Otherwise I refer to the beginning of this mail, a change is reflected by an operation call upon the document. Hope you are having a great day! Patrick Hope you are having a great day as well! Svante On 09/20/2012 05:49 AM, Svante Schubert wrote: Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become fixed so that change tracking is engaged again? With fixed you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Which is one presumption but perhaps not the one that the TC desires to make. The TC is likely to favor the easiest and efficient model being offered. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text).  From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by style blends from the application vendors. For instance, the heading 1 style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). Not objecting to your answer but it leaves out a lot of detail. ;-) Sure, just wanted to keep the mail short ;) Hope you are having a great day! Patrick Hope you are having a great day as well! Svante --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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 Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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

<office-collab@lists.oasis-open.org> wrote on 09/20/2012 04:41:50 PM: > > Svante, > > OK, trying again: > > When you say: > Not being saved. I can rewrite a sentence a dozen times , in the end > it is only saved the delta from the start and the end of the > session. In other words the operations are being compressed to > express the information set representing the session delta. > > What is a session? > What you have is an initial document model A, and a modified document model A'. The change tracking problem is defining a vocabulary for specifying set of operations on document A that will transform it into document A', for all possible A' that may be derived from A via editing operations.  (And yes, we'll need to enumerate those editing operations). Although it is possible for a pathological editor to specify the transformation of "x" -> "y" as first inserting "z", then deleting "z" and appending "y", I'm not sure we need to forbid this.  So long is the transformation yields the correct end state, we could allow implementation-dependent optimizations for reducing the "edit distance" from A to A'.  But there might be practical constraints in any given implementation.  Perhaps an editor can coalesce multiple edits to the same <p> but not handle this as well for cut & paste operations between paragraphs.  Requiring perfection here would require an implementation to store an arbitrarily long stack of editing operations, something I don't think we want to require. > If I save my document with tracking on and change a change (deleting > the "b" character) that was tracked, without accepting the changes: > > <text:change-start text:change- > id="ct139634698526728"/>a<text:change-end text:change-id="ct139634698526728"/> > > Previously, before the save, this read: > > <text:change-start text:change- > id="ct139634698526728"/>ab<text:change-end text:change- > id="ct139634698526728"/> > > Now I save and *close* the file, is that a session? > > <text:change-start text:change- > id="ct139634712754456"/>a<text:change-end text:change-id="ct139634712754456"/> > > IDs get changed on reload, but changing a change, is still not > captured, after save and close of file. > > So far, at least in the OpenOffice implementation: > > 1) save does not end a session > > 2) save and closing document does not end a session > > 3) ending change tracking does not end a session > > Of course, OpenOffice does not implement "to be specified operations > based CT" but that means we have to define what is meant by "session." > > I remain convinced this is possible or I would not be pushing so hard on it. > > Hope you are having a great day! > > Patrick > On 09/20/2012 03:57 PM, Svante Schubert wrote: > On 20.09.2012 15:26, Patrick Durusau wrote: > Svante, > On 09/20/2012 08:35 AM, Svante Schubert wrote: > Hi Patrick, > > <snip> > > When forward progress of the text stops? When I stop deleting the > inserted text? When the cursor has moved off the inserted text > (after deletions/additions)? Or the cursor has left the inserted > text for more than 5 seconds? After a save? > Why shall we care? This is absolutely an implementation detail of > the application, all we have to care about is that similar changes > are able to be reflected by different set(s) of operations, which > all have in common that they have the same information set, > resulting in the end into an equal change. > For instance, instead of three operations: > 1. insert "a" in paragraph 1 at position 1 > 2. insert "b" in paragraph 1 at position 2 > 3. insert "c" in paragraph 1 at position 3 > The application might as well sent one operation: > 1. insert "abc" in paragraph 1 at position 1 > AFAIK Google Docs is pushing every change right away to the server, > like editing in a field using AJAX. > > We should care because we are *not* writing a protocol for > interchange of change tracking information. > I suggest we do not invest too much energies to focus on what we > should *not* do, who has a benefit from that attitude? > Focus on what we are able to archive for our goal of change-racking. > To allow an ODF application to undo changes made by another ODF > application has much to do of of the interchange of change > information. But perhaps we are just again at cross-purposes.. > We are writing a format to track changes in a file format for > reading and presentation to a user (same or another user), post > change. On the same or a different application. > > What is meant by: "..resulting in the end of an equal change?" > That the state of the document is the same. > > I perform the following operations: > 1. insert "a" in paragraph 1 at position 1 > 2. insert "b" in paragraph 1 at position 2 > 3. insert "c" in paragraph 1 at position 3 > I move off that changed text and perform changes elsewhere. > I return to the abc text, which shows "change" in my interface and: > 4. delete "c" in paragraph 1 at position 3 > Question: Is that reflected in the *markup syntax* that is saved as > part of the document? > Not being saved. I can rewrite a sentence a dozen times , in the end > it is only saved the delta from the start and the end of the > session. In other words the operations are being compressed to > express the information set representing the session delta. > Here is what I get with the latest version of OpenOffice: > <text:change-start text:change- > id="ct139634698526728"/>ab<text:change-end text:change- > id="ct139634698526728"/> > The rest of the changes tracking: > def in paragraph 2 at positions 1, 2, 3 > ghi in paragraph 3 at positions 1, 2, 3 > I conclude that changes to changes are not tracked in OpenOffice. > Sure. > That could be a *serious* failing if we are tracking changes by > authors and a subsequent author can change my change and it still > shows up as my change, albeit not as I changed it. > No problem as far as I see... > Hope you are having a great day! > Same to you, > Svante > Patrick > > > > > Changing the position pointer (start or end) may be part of a > definition of change but it is a fairly crude one. > Only if the position pointer is part of the document state to be > changes, AFAIK OOo is saving it into the settings.xml properties. > Otherwise I refer to the beginning of this mail, a change is > reflected by an operation call upon the document. > Hope you are having a great day! > > Patrick > Hope you are having a great day as well! > Svante > > > On 09/20/2012 05:49 AM, Svante Schubert wrote: > Hi Patrick, > > On 19.09.2012 17:04, Patrick Durusau wrote: > Svante, > > > On 09/19/2012 08:35 AM, Svante Schubert wrote: > Hi Patrick, > <snip> > That is at what time does the state of the text become "fixed" so that > change tracking is engaged again? > With "fixed" you might as well think about a compression/condensation of > operations. For example, if someone inserts a word and deletes it again, > it will not occur in the CT, although there had been two operations. > That was my question. > > You are presuming a model that does not track changes to changes. > Might be philosophical, as every operation creates a new independent > document state. Therefore two (or more) sequential operations changing > the same data, could be interpreted either as two (or more) independent > changes of the document state or as a change of a change. > > After realizing both views are equivalent it is much easier to work > solely with the prior model, where each change is independent and > movable along the sequence of operations (presuming to do the required > OT adaption during movement, i.e. whenever passing a create/delete > operation that influence the position of the moving operation > de/increase the position integer). > Which is one presumption but perhaps not the one that the TC desires > to make. > The TC is likely to favor the easiest and efficient model being offered. > Can think of compression/condensation of operations but that means the > CT syntax has to record multiple changes, say make bold and italic > instead of separate operations of bold, then italic (on the same text). >  From a abstract high level view, changing the style on text is nothing > more than an change of properties on a sequence of the document. Someone > might change a single property or multiple properties. Latter might be > done via operations by either passing all properties along or defining a > set beforehand. Someone might even have the vision that some style sets > are being defined before the operations occurs (to follow our convention > over configuration approach), either within the document (as a given > style set) or preferable within the ODF specification, by "style blends" > from the application vendors. For instance, the "heading 1" style set > might be defined before hand, instead of passing the styles for every > document being opened. > > Various compressions are thinkable, all they have to have in common is > to keep the information set equivalent. > And, it means we have to define when compression/condensation occurs > and how it is recorded in syntax. > Uncertain yet, if we have to be necessarily such strict. We definitely > have to define what operations are equivalent. We could even come up > with a normalized form of operations (the most efficient form of > operations to be exchanged). > Not objecting to your answer but it leaves out a lot of detail. ;-) > Sure, just wanted to keep the mail short ;) > Hope you are having a great day! > > Patrick > Hope you are having a great day as well! > Svante > > --------------------------------------------------------------------- > To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: office-collab-help@lists.oasis-open.org > > -- > Patrick Durusau > patrick@durusau.net > Former Chair, V1 - US TAG to JTC 1/SC 34 > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > 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 > Former Chair, V1 - US TAG to JTC 1/SC 34 > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > 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

Hi, some insight to Apache OpenOffice (incubating)/OpenOffice.org change tracking: - Yes, AOO tries to be "intelligent" regarding changes made by a certain author to her/his own changes. - making a change to change in a certain time frame - I think these are minutes - are "combined"; even if the document has been save-close-reopened in between. Thus, we you delete a character that you have inserted before you end up with no change. - just start with an empty document and activate change tracking. Then type some characters, but wait at least a minute between each character. You will end up with several tracked changes - one for each character. - I hope that a "session" ends at least when another author has touched the document. Mit freundlichen Grüßen / Best regards Oliver-Rainer Wittmann -- Advisory Software Engineer ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Beim Strohhause 17 20097 Hamburg Phone: +49-40-6389-1415 E-Mail: orwitt@de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 From: Patrick Durusau <patrick@durusau.net> To: office-collab@lists.oasis-open.org Date: 20.09.2012 22:41 Subject: Re: [office-collab] Multiple changes Sent by: <office-collab@lists.oasis-open.org> Svante, OK, trying again: When you say: Not being saved. I can rewrite a sentence a dozen times , in the end it is only saved the delta from the start and the end of the session. In other words the operations are being compressed to express the information set representing the session delta. What is a session? If I save my document with tracking on and change a change (deleting the "b" character) that was tracked, without accepting the changes: <text:change-start text:change-id="ct139634698526728"/>a<text:change-end text:change-id="ct139634698526728"/> Previously, before the save, this read: <text:change-start text:change-id="ct139634698526728"/>ab<text:change-end text:change-id="ct139634698526728"/> Now I save and *close* the file, is that a session? <text:change-start text:change-id="ct139634712754456"/>a<text:change-end text:change-id="ct139634712754456"/> IDs get changed on reload, but changing a change, is still not captured, after save and close of file. So far, at least in the OpenOffice implementation: 1) save does not end a session 2) save and closing document does not end a session 3) ending change tracking does not end a session Of course, OpenOffice does not implement "to be specified operations based CT" but that means we have to define what is meant by "session." I remain convinced this is possible or I would not be pushing so hard on it. Hope you are having a great day! Patrick On 09/20/2012 03:57 PM, Svante Schubert wrote: On 20.09.2012 15:26, Patrick Durusau wrote: Svante, On 09/20/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> When forward progress of the text stops? When I stop deleting the inserted text? When the cursor has moved off the inserted text (after deletions/additions)? Or the cursor has left the inserted text for more than 5 seconds? After a save? Why shall we care? This is absolutely an implementation detail of the application, all we have to care about is that similar changes are able to be reflected by different set(s) of operations, which all have in common that they have the same information set, resulting in the end into an equal change. For instance, instead of three operations: 1. insert "a" in paragraph 1 at position 1 2. insert "b" in paragraph 1 at position 2 3. insert "c" in paragraph 1 at position 3 The application might as well sent one operation: 1. insert "abc" in paragraph 1 at position 1 AFAIK Google Docs is pushing every change right away to the server, like editing in a field using AJAX. We should care because we are *not* writing a protocol for interchange of change tracking information. I suggest we do not invest too much energies to focus on what we should *not* do, who has a benefit from that attitude? Focus on what we are able to archive for our goal of change-racking. To allow an ODF application to undo changes made by another ODF application has much to do of of the interchange of change information. But perhaps we are just again at cross-purposes.. We are writing a format to track changes in a file format for reading and presentation to a user (same or another user), post change. On the same or a different application. What is meant by: "..resulting in the end of an equal change?" That the state of the document is the same. I perform the following operations: 1. insert "a" in paragraph 1 at position 1 2. insert "b" in paragraph 1 at position 2 3. insert "c" in paragraph 1 at position 3 I move off that changed text and perform changes elsewhere. I return to the abc text, which shows "change" in my interface and: 4. delete "c" in paragraph 1 at position 3 Question: Is that reflected in the *markup syntax* that is saved as part of the document? Not being saved. I can rewrite a sentence a dozen times , in the end it is only saved the delta from the start and the end of the session. In other words the operations are being compressed to express the information set representing the session delta. Here is what I get with the latest version of OpenOffice: <text:change-start text:change-id="ct139634698526728"/> ab<text:change-end text:change-id="ct139634698526728"/> The rest of the changes tracking: def in paragraph 2 at positions 1, 2, 3 ghi in paragraph 3 at positions 1, 2, 3 I conclude that changes to changes are not tracked in OpenOffice. Sure. That could be a *serious* failing if we are tracking changes by authors and a subsequent author can change my change and it still shows up as my change, albeit not as I changed it. No problem as far as I see... Hope you are having a great day! Same to you, Svante Patrick Changing the position pointer (start or end) may be part of a definition of change but it is a fairly crude one. Only if the position pointer is part of the document state to be changes, AFAIK OOo is saving it into the settings.xml properties. Otherwise I refer to the beginning of this mail, a change is reflected by an operation call upon the document. Hope you are having a great day! Patrick Hope you are having a great day as well! Svante On 09/20/2012 05:49 AM, Svante Schubert wrote: Hi Patrick, On 19.09.2012 17:04, Patrick Durusau wrote: Svante, On 09/19/2012 08:35 AM, Svante Schubert wrote: Hi Patrick, <snip> That is at what time does the state of the text become "fixed" so that change tracking is engaged again? With "fixed" you might as well think about a compression/condensation of operations. For example, if someone inserts a word and deletes it again, it will not occur in the CT, although there had been two operations. That was my question. You are presuming a model that does not track changes to changes. Might be philosophical, as every operation creates a new independent document state. Therefore two (or more) sequential operations changing the same data, could be interpreted either as two (or more) independent changes of the document state or as a change of a change. After realizing both views are equivalent it is much easier to work solely with the prior model, where each change is independent and movable along the sequence of operations (presuming to do the required OT adaption during movement, i.e. whenever passing a create/delete operation that influence the position of the moving operation de/increase the position integer). Which is one presumption but perhaps not the one that the TC desires to make. The TC is likely to favor the easiest and efficient model being offered. Can think of compression/condensation of operations but that means the CT syntax has to record multiple changes, say make bold and italic instead of separate operations of bold, then italic (on the same text). From a abstract high level view, changing the style on text is nothing more than an change of properties on a sequence of the document. Someone might change a single property or multiple properties. Latter might be done via operations by either passing all properties along or defining a set beforehand. Someone might even have the vision that some style sets are being defined before the operations occurs (to follow our convention over configuration approach), either within the document (as a given style set) or preferable within the ODF specification, by "style blends" from the application vendors. For instance, the "heading 1" style set might be defined before hand, instead of passing the styles for every document being opened. Various compressions are thinkable, all they have to have in common is to keep the information set equivalent. And, it means we have to define when compression/condensation occurs and how it is recorded in syntax. Uncertain yet, if we have to be necessarily such strict. We definitely have to define what operations are equivalent. We could even come up with a normalized form of operations (the most efficient form of operations to be exchanged). Not objecting to your answer but it leaves out a lot of detail. ;-) Sure, just wanted to keep the mail short ;) Hope you are having a great day! Patrick Hope you are having a great day as well! Svante --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- Patrick Durusau patrick@durusau.net Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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 Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) 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