OpenDocument - Adv Document Collab SC

Greetings! I have been thinking about our discussion of counting and related issues, both on the list and in the last call. I take it that change tracking at its most fundamental has two aspects: 1) Identify the location of a change. 2) Specify the change to be made. Both of those are present whatever the change tracking mechanism (or format). Following closely onto those two, however, is the common experience of turning change tracking on and also turning it off. Perhaps is a single editing session by a single user. But it is certainly the case that a document (in its broadest sense) can pass through several hands, all of which may turn change tracking on or off and all of who may make changes to the documents as well as accept or reject them. (I need to post the multi-user making/accepting/rejecting comments into a requirement but that is for a separate post.) I have the sense that turning change tracking on/off is nearly as universal a requirement as identification of location and specification of the change to be made. Is that a fair statement? Hope everyone is having a great weekend! Patrick PS: I don't see any of these three requirements driving a particular result for operations based change tracking. -- 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

On Sat, 2012-09-29 at 13:18 -0600, Patrick Durusau wrote: > Following closely onto those two, however, is the common experience of > turning change tracking on and also turning it off. > > Perhaps is a single editing session by a single user. > > But it is certainly the case that a document (in its broadest sense) can > pass through several hands, all of which may turn change tracking on or > off and all of who may make changes to the documents as well as accept > or reject them. > > (I need to post the multi-user making/accepting/rejecting comments into > a requirement but that is for a separate post.) > > I have the sense that turning change tracking on/off is nearly as > universal a requirement as identification of location and specification > of the change to be made. > > Is that a fair statement? I really don't understand how the fact that users can turn change tracking off or on some applications is related the the ODF file format. I would think that the file format should store the current file and any change tracking information that has been collected. Whether there may have been some changes made for which change tracking info is not available is really not important. Of course one would expect that the change tracking information stored is in fact compatible with the current file content. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

Andreas, First, thanks for the example which may do more to clarify this issue than anything I have posted to date! Second, a comment below about relevance to the format: (you may want to jump all the way to the end where I may get it right. I have preserved the first part just in case I didn't.) On 09/29/2012 07:56 PM, Andreas J. Guelzow wrote: On Sat, 2012-09-29 at 13:18 -0600, Patrick Durusau wrote: Following closely onto those two, however, is the common experience of turning change tracking on and also turning it off. <snip> Is that a fair statement? I really don't understand how the fact that users can turn change tracking off or on some applications is related the the ODF file format. I would think that the file format should store the current file and any change tracking information that has been collected. Well, the capacity to turn change tracking on or off can have an impact on design of the CT format for ODF. For example, say that change tracking is stored in the content.xml file by the simple expedient of surrounding or creating well-formed XML segments. That is to have: <text:p>A paragraph</text:p> <del><text:p>Deleted paragraph</text:p></del> <text:p>Another paragraph</text:p> To represent where the "second" paragraph in this view has been marked as deleted. (Leaving aside all the downsides of such a method, it is for illustration purposes only.) The add/del of any track changes appears directly in the markup stream so turning it on or off, leaves the application able to apply every change before change tracking is turned off and to apply every change after change tracking is turned back on. Yes? Now, assume that staying with an all <text:p> example (apologies to Dennis but Knuth says it is easier to start with simple examples and work your way up), we have: <text:p>A paragraph</text:p> <text:p>Paragraph that will be deleted - no change tracking</text:p> <text:p>Another paragraph</text:p> <text:p>Paragraph to be inserted - with change tracking</text:p> <text:p>Yet another paragraph</text:p> Let's assume we are counting <text:p> as components and with change tracking on, we want to insert a paragraph following the third paragraph. So we count down to the third paragraph and insert: <text:p>Paragraph to be inserted - with change tracking on</text:p> How do we record the insertion point in the ODF format for that change? Do we say, insert after the 3rd paragraph? The reason that *may be* (not sure yet) problematic is that later in editing the file, with change tracking off, we delete: <text:p>Paragraph that will be deleted - no change tracking</text:p> So that: <text:p #1>A paragraph</text:p> <text:p #2>Paragraph that will be deleted - no change tracking</text:p> <text:p #3>Another paragraph</text:p> <text:p #4>Paragraph to be inserted - with change tracking</text:p> <text:p #5>Yet another paragraph</text:p> becomes <text:p #1>A paragraph</text:p> <text:p #2>Another paragraph</text:p> <text:p #3>Paragraph to be inserted - with change tracking</text:p> <text:p #4>Yet another paragraph</text:p> Where is the numbering that I can tie the change tracking to? Hasn't it changed? That is the "format" impact of turning change tracking on/off is on the "matching" mechanism we use to align changes to the text. Whether there may have been some changes made for which change tracking info is not available is really not important. Of course one would expect that the change tracking information stored is in fact compatible with the current file content. This may be what you are capturing with your "...in fact compatible with the current file format." It could be that I am viewing the serialization as "fixed" at the wrong point in time. That is when the content, along with changes, is serialized to the ODF format, that all changes, dels/adds, etc. are written to their *current* locations, not the locations when changes were made. Is that what you meant? Andreas -- 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

On Sun, 2012-09-30 at 04:11 -0600, Patrick Durusau wrote: > First, thanks for the example which may do more to clarify this issue > than anything I have posted to date! > > Second, a comment below about relevance to the format: > > (you may want to jump all the way to the end where I may get it right. I > have preserved the first part just in case I didn't.) > > On 09/29/2012 07:56 PM, Andreas J. Guelzow wrote: > > On Sat, 2012-09-29 at 13:18 -0600, Patrick Durusau wrote: > > > >> Following closely onto those two, however, is the common experience of > >> turning change tracking on and also turning it off. > <snip> > >> Is that a fair statement? > > I really don't understand how the fact that users can turn change > > tracking off or on some applications is related the the ODF file format. > > I would think that the file format should store the current file and any > > change tracking information that has been collected. > > Well, the capacity to turn change tracking on or off can have an impact > on design of the CT format for ODF. I still don't see that. > > For example, say that change tracking is stored in the content.xml file > by the simple expedient of surrounding or creating well-formed XML > segments. > > That is to have: > > <text:p>A paragraph</text:p> > <del><text:p>Deleted paragraph</text:p></del> > <text:p>Another paragraph</text:p> > > To represent where the "second" paragraph in this view has been marked > as deleted. > > (Leaving aside all the downsides of such a method, it is for > illustration purposes only.) > > The add/del of any track changes appears directly in the markup stream > so turning it on or off, leaves the application able to apply every > change before change tracking is turned off and to apply every change > after change tracking is turned back on. > > Yes? > > Now, assume that staying with an all <text:p> example (apologies to > Dennis but Knuth says it is easier to start with simple examples and > work your way up), we have: > > <text:p>A paragraph</text:p> > <text:p>Paragraph that will be deleted - no change tracking</text:p> > <text:p>Another paragraph</text:p> > <text:p>Paragraph to be inserted - with change tracking</text:p> > <text:p>Yet another paragraph</text:p> > > Let's assume we are counting <text:p> as components and with change > tracking on, we want to insert a paragraph following the third > paragraph. So we count down to the third paragraph and insert: > > <text:p>Paragraph to be inserted - with change tracking on</text:p> > > How do we record the insertion point in the ODF format for that change? > Do we say, insert after the 3rd paragraph? > > The reason that *may be* (not sure yet) problematic is that later in > editing the file, with change tracking off, we delete: > > <text:p>Paragraph that will be deleted - no change tracking</text:p> > > So that: > > <text:p #1>A paragraph</text:p> > <text:p #2>Paragraph that will be deleted - no change tracking</text:p> > <text:p #3>Another paragraph</text:p> > <text:p #4>Paragraph to be inserted - with change tracking</text:p> > <text:p #5>Yet another paragraph</text:p> > > becomes > > <text:p #1>A paragraph</text:p> > <text:p #2>Another paragraph</text:p> > <text:p #3>Paragraph to be inserted - with change tracking</text:p> > <text:p #4>Yet another paragraph</text:p> > > Where is the numbering that I can tie the change tracking to? Hasn't it > changed? > > That is the "format" impact of turning change tracking on/off is on the > "matching" mechanism we use to align changes to the text. > > > Whether there may have been some changes made for which change tracking > > info is not available is really not important. Of course one would > > expect that the change tracking information stored is in fact compatible > > with the current file content. > > This may be what you are capturing with your "...in fact compatible with > the current file format." yes > > It could be that I am viewing the serialization as "fixed" at the wrong > point in time. It appears to me as if you are assuming that the application works directly on the xml code as the program runs and the user interacts. Is there any implementation which does that. I would assume that this would yield horrible performance. I assume that serialization only happens when the file is written. When it is read deserialization occurs. So there would be no changes tot he file while it is serialized. > > That is when the content, along with changes, is serialized to the ODF > format, that all changes, dels/adds, etc. are written to their *current* > locations, not the locations when changes were made. > > Is that what you meant? Yes, exactly that's what I was thinking. Note that as long as the file as written is consistent with the recorded change-tracking we would not need to address the question of whether the ability to turn change-tracking off while retaining the change track info is an urban myth or not. That would all be in the realm of application features. Andreas > -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

In the spirit of starting with simple examples, here's one similar to what Patrick introduced. I am not assuming which approach to change-tracking is used beyond assuming that the persistent form of the document can be read as if the changes are all applied when change-tracking is ignored. ORIGINAL SPECIMEN <text:p text-attributes1>Consider that: </text:p> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> The user deletes, as a single operation, the text from the ":" to the text ending "ACKXX". If this is allowed as a single deletion (it is in current ODF 1.2 implementations of change-tracking) at least two things will happen: The resulting text will often be persisted as <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> And something like the following will be captured elsewhere to reflect the deleted content: <text:p text-attributes1>: </text:p> <text:p text-attributes2>ACKXX</text:p> There is additional markup to know where the deletion point is and information sufficient for (1) revoking the change, (2) accepting the change (trivial), and also (3) being able to display the text with change tracking in-line with distinctive markup. (The ODF specification doesn't address these, but it is required to afford these activities in a practical implementation.) Note that the formatting differences of the second paragraph are lost. This is typical of what happens if the user takes no further action to remedy that. Another way to handle that would be with something like this in the persisted post-deletion markup: <text:p><text:span text-attributes1>Consider that</text:span><!-- deletion point --><text:span text-attributes2> once upon a time there were three little pigs.</text:span></text:p> although this requires an implementation that makes it easy for users to recognized and control <text:span> effects. THE PUZZLE How is this case handled in the MCT proposal? I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected. BONUS POINTS In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>. - Dennis PS: Knuth has said as much to me, although when I saw him in June, change-tracking was not part of the conversation [;<). The problem is not with simple examples, it is with solutions that are simple only for the wrong problem.
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Sunday, September 30, 2012 03:12 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] Now, assume that staying with an all <text:p> example (apologies to Dennis but Knuth says it is easier to start with simple examples and work your way up), we have: <text:p>A paragraph</text:p> <text:p>Paragraph that will be deleted - no change tracking</text:p> <text:p>Another paragraph</text:p> <text:p>Paragraph to be inserted - with change tracking</text:p> <text:p>Yet another paragraph</text:p> [ ... ]

And isn't there another set of cases? This discussion seems to assume that the application actors all understand (all) change tracking. What about round-tripping of a document through an application that doesn't understand change tracking? It should be able to preserve CT in areas of the document that it doesn't modify. With relative referencing, even changes in other parts of the document can invalidate that, right? Imagine a simple doc with a few sentences. User 1 in app 1 which understands CT deletes the third sentence and tracks the change. This is persisted outside the main text as a deletion of the 3rd sentence. User 1 sends the doc to user 2 who uses app 2 which doesn't support change tracking. User 2 adds a new sentence at the beginning of the paragraph. That reference to deleting the 3rd sentence is now wrong and the doc will display incorrectly when user 2 sends it back to user 1. Further, I suppose this new relative referencing design means that all ODF clients MUST support CT to avoid breaking documents and so that they display the doc correctly? One of the tenets I had in considering ECT was to preserve the current behavior where simpler ODF clients didn't need to understand change tracking and the content in content.xml would always represent the "latest" state of the doc (as if all changes were accepted). This latter concept was important enough that the GCT proposal was modified to allow for it. Does MCT change both of these tenets now? Perhaps I'm missing something big, since there's no single collection of the bottom line of MCT in one place; I may be missing something that's in the presentation and hundred or so e-mails. John
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Dennis E. Hamilton Sent: Monday, October 01, 2012 9:06 AM To: office-collab@lists.oasis-open.org Subject: RE: [office-collab] Counting issues, etc In the spirit of starting with simple examples, here's one similar to what Patrick introduced. I am not assuming which approach to change-tracking is used beyond assuming that the persistent form of the document can be read as if the changes are all applied when change-tracking is ignored. ORIGINAL SPECIMEN <text:p text-attributes1>Consider that: </text:p> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> The user deletes, as a single operation, the text from the ":" to the text ending "ACKXX". If this is allowed as a single deletion (it is in current ODF 1.2 implementations of change-tracking) at least two things will happen: The resulting text will often be persisted as <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> And something like the following will be captured elsewhere to reflect the deleted content: <text:p text-attributes1>: </text:p> <text:p text-attributes2>ACKXX</text:p> There is additional markup to know where the deletion point is and information sufficient for (1) revoking the change, (2) accepting the change (trivial), and also (3) being able to display the text with change tracking in-line with distinctive markup. (The ODF specification doesn't address these, but it is required to afford these activities in a practical implementation.) Note that the formatting differences of the second paragraph are lost. This is typical of what happens if the user takes no further action to remedy that. Another way to handle that would be with something like this in the persisted post-deletion markup: <text:p><text:span text-attributes1>Consider that</text:span><!-- deletion point --><text:span text-attributes2> once upon a time there were three little pigs.</text:span></text:p> although this requires an implementation that makes it easy for users to recognized and control <text:span> effects. THE PUZZLE How is this case handled in the MCT proposal? I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected. BONUS POINTS In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>. - Dennis PS: Knuth has said as much to me, although when I saw him in June, change-tracking was not part of the conversation [;<). The problem is not with simple examples, it is with solutions that are simple only for the wrong problem.
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Sunday, September 30, 2012 03:12 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] Now, assume that staying with an all <text:p> example (apologies to Dennis but Knuth says it is easier to start with simple examples and work your way up), we have: <text:p>A paragraph</text:p> <text:p>Paragraph that will be deleted - no change tracking</text:p> <text:p>Another paragraph</text:p> <text:p>Paragraph to be inserted - with change tracking</text:p> <text:p>Yet another paragraph</text:p> [ ... ] --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org

John, I have confused myself over these very issues so let me see if I can now (subject to correction by others) state it correctly. Using your simple doc case: Imagine a simple doc with a few sentences. User 1 in app 1 which understands CT deletes the third sentence and tracks the change. This is persisted outside the main text as a deletion of the 3rd sentence. User 1 sends the doc to user 2 who uses app 2 which doesn't support change tracking. User 2 adds a new sentence at the beginning of the paragraph. That reference to deleting the 3rd sentence is now wrong and the doc will display incorrectly when user 2 sends it back to user 1. First, I think Andreas made the point that the change tracking syntax reports to the application changes that would have to be made to the "current" text to restore it to some prior condition. That is to say, the "current" text as saved to an ODF conforming file, is the text as though all changes have been accepted. There isn't any, "this used to be paragraph 4 but then I added paragraph 2b," etc. Changes (operations) are expressed against the text as written out in ODF format. That gives us a common start/end point for judging the writing of the operations against the "current" text. If a non-change tracking enabled application simply prints the "current" text, that is what it gets, as though all changes had been accepted. Does that work so far? What to get us started off on a common point before getting into intervening, non-change tracking applications. Hope you are having a great day! Patrick On 10/01/2012 03:29 PM, John Haug wrote: And isn't there another set of cases? This discussion seems to assume that the application actors all understand (all) change tracking. What about round-tripping of a document through an application that doesn't understand change tracking? It should be able to preserve CT in areas of the document that it doesn't modify. With relative referencing, even changes in other parts of the document can invalidate that, right? Imagine a simple doc with a few sentences. User 1 in app 1 which understands CT deletes the third sentence and tracks the change. This is persisted outside the main text as a deletion of the 3rd sentence. User 1 sends the doc to user 2 who uses app 2 which doesn't support change tracking. User 2 adds a new sentence at the beginning of the paragraph. That reference to deleting the 3rd sentence is now wrong and the doc will display incorrectly when user 2 sends it back to user 1. Further, I suppose this new relative referencing design means that all ODF clients MUST support CT to avoid breaking documents and so that they display the doc correctly? One of the tenets I had in considering ECT was to preserve the current behavior where simpler ODF clients didn't need to understand change tracking and the content in content.xml would always represent the "latest" state of the doc (as if all changes were accepted). This latter concept was important enough that the GCT proposal was modified to allow for it. Does MCT change both of these tenets now? Perhaps I'm missing something big, since there's no single collection of the bottom line of MCT in one place; I may be missing something that's in the presentation and hundred or so e-mails. John
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Dennis E. Hamilton Sent: Monday, October 01, 2012 9:06 AM To: office-collab@lists.oasis-open.org Subject: RE: [office-collab] Counting issues, etc In the spirit of starting with simple examples, here's one similar to what Patrick introduced. I am not assuming which approach to change-tracking is used beyond assuming that the persistent form of the document can be read as if the changes are all applied when change-tracking is ignored. ORIGINAL SPECIMEN <text:p text-attributes1>Consider that: </text:p> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> The user deletes, as a single operation, the text from the ":" to the text ending "ACKXX". If this is allowed as a single deletion (it is in current ODF 1.2 implementations of change-tracking) at least two things will happen: The resulting text will often be persisted as <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> And something like the following will be captured elsewhere to reflect the deleted content: <text:p text-attributes1>: </text:p> <text:p text-attributes2>ACKXX</text:p> There is additional markup to know where the deletion point is and information sufficient for (1) revoking the change, (2) accepting the change (trivial), and also (3) being able to display the text with change tracking in-line with distinctive markup. (The ODF specification doesn't address these, but it is required to afford these activities in a practical implementation.) Note that the formatting differences of the second paragraph are lost. This is typical of what happens if the user takes no further action to remedy that. Another way to handle that would be with something like this in the persisted post-deletion markup: <text:p><text:span text-attributes1>Consider that</text:span><!-- deletion point --><text:span text-attributes2> once upon a time there were three little pigs.</text:span></text:p> although this requires an implementation that makes it easy for users to recognized and control <text:span> effects. THE PUZZLE How is this case handled in the MCT proposal? I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected. BONUS POINTS In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>. - Dennis PS: Knuth has said as much to me, although when I saw him in June, change-tracking was not part of the conversation [;<). The problem is not with simple examples, it is with solutions that are simple only for the wrong problem.
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Sunday, September 30, 2012 03:12 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] Now, assume that staying with an all <text:p> example (apologies to Dennis but Knuth says it is easier to start with simple examples and work your way up), we have: <text:p>A paragraph</text:p> <text:p>Paragraph that will be deleted - no change tracking</text:p> <text:p>Another paragraph</text:p> <text:p>Paragraph to be inserted - with change tracking</text:p> <text:p>Yet another paragraph</text:p> [ ... ] --------------------------------------------------------------------- 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

On Mon, 2012-10-01 at 15:20 -0600, Patrick Durusau wrote: > John, > > I have confused myself over these very issues so let me see if I can now > (subject to correction by others) state it correctly. > > Using your simple doc case: > > > Imagine a simple doc with a few sentences. User 1 in app 1 which understands CT deletes the third sentence and tracks the change. This is persisted outside the main text as a deletion of the 3rd sentence. User 1 sends the doc to user 2 who uses app 2 which doesn't support change tracking. User 2 adds a new sentence at the beginning of the paragraph. That reference to deleting the 3rd sentence is now wrong and the doc will display incorrectly when user 2 sends it back to user 1. > > First, I think Andreas made the point that the change tracking syntax > reports to the application changes that would have to be made to the > "current" text to restore it to some prior condition. Yes. I think this is very important. Ignoring all change tracking info the document must look like all changes have been applied. John wrote earlier today "One of the tenets I had in considering ECT was to preserve the current behavior where simpler ODF clients didn't need to understand change tracking and the content in content.xml would always represent the "latest" state of the doc (as if all changes were accepted). This latter concept was important enough that the GCT proposal was modified to allow for it." I would postulate that this is as important now as it was when GCT was modified. > > That is to say, the "current" text as saved to an ODF conforming file, > is the text as though all changes have been accepted. > > There isn't any, "this used to be paragraph 4 but then I added paragraph > 2b," etc. Changes (operations) are expressed against the text as written > out in ODF format. > > That gives us a common start/end point for judging the writing of the > operations against the "current" text. > > If a non-change tracking enabled application simply prints the "current" > text, that is what it gets, as though all changes had been accepted. > > Does that work so far? > > What to get us started off on a common point before getting into > intervening, non-change tracking applications. Since I come from the spreadsheet side rather than the word processing side, it is difficult for me to imagine that one could permit any changes by a non-change-tracking aware application and hope that the change tracking info survives unscathed: If I try to translate this in to wordprocessing land I have: 1) Imagine a <text:conditional-text> element inside a <text:p> that has a condition that refers to a table X elsewhere in the document. 2) The <text:conditional-text> element is deleted and that information stored in the appropriate change tracking markup. 3) A non-change tracking aware application deletes the table X (and retains all previous change tracking info) and creates a differnet table X alsewhere in the document. There is no way now that the first deletion can be reasonably rejected since the result of that undoing would create a very different document. Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

Dennis, On 10/01/2012 12:05 PM, Dennis E. Hamilton wrote: In the spirit of starting with simple examples, here's one similar to what Patrick introduced. I am not assuming which approach to change-tracking is used beyond assuming that the persistent form of the document can be read as if the changes are all applied when change-tracking is ignored. ORIGINAL SPECIMEN <text:p text-attributes1>Consider that: </text:p> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> The user deletes, as a single operation, the text from the ":" to the text ending "ACKXX". If this is allowed as a single deletion (it is in current ODF 1.2 implementations of change-tracking) at least two things will happen: The resulting text will often be persisted as <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> And something like the following will be captured elsewhere to reflect the deleted content: <text:p text-attributes1>: </text:p> <text:p text-attributes2>ACKXX</text:p> This is our first point of departure. That is *not* what is captured elsewhere. How an application "captures" the change isn't nor should it be any of our business. There is additional markup to know where the deletion point is and information sufficient for (1) revoking the change, (2) accepting the change (trivial), and also (3) being able to display the text with change tracking in-line with distinctive markup. (The ODF specification doesn't address these, but it is required to afford these activities in a practical implementation.) Note that the formatting differences of the second paragraph are lost. This is typical of what happens if the user takes no further action to remedy that. Another way to handle that would be with something like this in the persisted post-deletion markup: <text:p><text:span text-attributes1>Consider that</text:span><!-- deletion point --><text:span text-attributes2> once upon a time there were three little pigs.</text:span></text:p> although this requires an implementation that makes it easy for users to recognized and control <text:span> effects. THE PUZZLE How is this case handled in the MCT proposal? I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected. The text as saved by the application: <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> That is the text *against which* operations are expressed to record changes for acceptance/rejection by others. So that if I simply print the "text," I get it as if all changes have been accepted. I was expecting a fuller list of "components" but in their absence, consider if we use text-offsets (no attempt to formulate the change syntax): insert ":" at 14. create <text:p attributes2> at 19. (by well-formedness rule, now open elements must close) insert "ACKXXX " at 19. (note the text point is now inside the new paragraph. But also note that the operations are defined against the text *as known to the application* so shifting text locations are trivial to calculate.) BONUS POINTS In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>. <text:h text-attributes1>Consider that: </text:h> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> To anticipate interoperability questions, I think we need to define a default when deletions cross element boundaries, which typically mean a change in styles. So the question back to Dennis is: Do I have: <text:h text-attributes1>Consider that once upon a time there were three little pigs.</text:h> Or, <text:p text-attributes2>Consider that once upon a time there were three little pigs.</text:p> As the final text? Perhaps a better way to say the difference in MCT and proposals to date: Other proposals are capturing changes as they occur in markup syntax (or at least purport to). (A changing text.) MCT expresses changes against the final text to revert it to some earlier state. (A final text or at least one where I can reliably calculate character off-sets for example.) Yes? Hope you are having a great day! Patrick - Dennis PS: Knuth has said as much to me, although when I saw him in June, change-tracking was not part of the conversation [;<). The problem is not with simple examples, it is with solutions that are simple only for the wrong problem. Too bad. ;-) True, but simple examples cut away hidden assumptions, like applications caching their change tracking operations in markup for later serialization. I find that difficult to believe. Not that it could not happen. PS: I used character off-sets but you could just as easily, if not more so, use XPath expressions. Or a subset of XPath actually. Would be one less new thing to have to learn.
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Sunday, September 30, 2012 03:12 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] Now, assume that staying with an all <text:p> example (apologies to Dennis but Knuth says it is easier to start with simple examples and work your way up), we have: <text:p>A paragraph</text:p> <text:p>Paragraph that will be deleted - no change tracking</text:p> <text:p>Another paragraph</text:p> <text:p>Paragraph to be inserted - with change tracking</text:p> <text:p>Yet another paragraph</text:p> [ ... ] --------------------------------------------------------------------- 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 HAVE A CONCERN. I think a failure to appreciate what is currently supported, and why it is supported the way it is (whatever difficulties there are with its proper specification and implementation) risks a folly of the kind said about those who refuse to study history. This is especially a concern when it is claimed that the successor to ODF 1.0/1.1/1.2 change tracking will be able to accept or upgrade from (and downgrade to, where upgradeable from) the "legacy." This needs to be moved from a matter of belief to a matter of demonstrated fact. I use ODF CT here because there are implementations and behaviors that are known to be supported and working in more-or-less reliable ways. It is easy to construct simple but interesting cases and examine the resulting XML and see what works when it works. I gave a simple case of a commonly-supported deletion that crosses from the end of one paragraph into the beginning of another. Here's more explanation of what it is that GCT has to stack up against in that simple example. RESPONDING TO JUST THE FIRST PART ONLY: I meant "something like" to avoid getting into the details of how deleted material is made well-formed. I omitted the use of change marks and the way the material might be carried apart from showing how a deleted content fragment that severs elements can be adjusted to be content in a well-formed XML element. I also did not get into how such a well-formed XML element can be restored to the proper fragment if the deletion is rejected by a subsequent consumer. In particular, I was not saying what MCT is proposed to do, I was saying what must be accomplished in some manner if the example I gave is handled as a single deletion and expressed in XML. In fact, the current <text:tracked-changes> <text:changed-region> <text:deletion> holds a run of text-content patterns and the run of two <text:p> elements I provide below qualifies. If I had gotten specific about how this works in ODF 1.2, I would have shown the post-deletion paragraph this way: <text:p text-attributes1>Consider that<text:change> once upon a time there were three little pigs.</text:p> The <text:change> element can appear anywhere (runs of) paragraph-content can appear. It has a text:change-id attribute (of type IDREF) that identifies the <text:changed-region> element (by its xml:id) that has the <text:deletion> element carrying the deleted material. (Note that when these linkages are broken in either direction, a consumer can simply remove the appropriate widows and orphans, so broken connections can be cleaned up by CT-aware consumers, and damage left by CT-unaware consumers is to that extent self-healing.) Note that, no matter what else happens in the resulting paragraph in places separate from or even spanning the <text:change> marker, there is nothing that has to be recomputed. Text in the paragraph before the <text:change> marker can grow or shrink and it doesn't matter. Likewise, if there is a subsequent deletion via a different session/author that includes the <text:change> mark, that is also no problem. There is nothing that has to be figured out or adjusted to preserve the tracking of this particular deletion, even if it ends up inside tracked-deletion material. The user presentation and the acceptance/rejection process takes some care, but that's apparently the proper time to do it since something has to be done at that point regardless. It is a rocket- (i.e., computer-) science problem to specify it in a sound way though. I grant that ODF 1.2 CT is awesomely underspecified. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Tuesday, October 02, 2012 01:31 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] > The resulting text will often be persisted as > > <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> > > And something like the following will be captured elsewhere to reflect the deleted content: > > <text:p text-attributes1>: </text:p> > <text:p text-attributes2>ACKXX</text:p> This is our first point of departure. That is *not* what is captured elsewhere. How an application "captures" the change isn't nor should it be any of our business. [ ... ]

ADDITIONAL RESPONSE To be clear, my illustrations are of a portion of a document read by a CT-implementing consumer, and the persistent form produced by that consumer. When I speak of the user action and how that producer responds, it is only meant to illustrate what is essential for the producer to arrive at the produced form of the change. In the case of the simple example, it is a deletion that crosses from the end of one paragraph-content element into the beginning of the following paragraph-content element and is implemented as a single deletion. This is a genuine use case, even though what happens at the ODF format level is simply that there is an expression of it in the persistent XML that is produced. So when I speak of what is captured somewhere, I mean in the persistent form and was not intending to imply anything about what happens internally or even what is acted upon internally. With regard to the persisted XML after the deletion in my example, there is nothing unusual in the resulting paragraph text apart from the fact that, for ODF 1.2, there will be a marker element at the point where the deletion happened. This little scar tissue contributes no content and is ignored by non-CT-aware applications. If there are no markers in the case of MCT, that makes it interesting to find when that portion of the input has a history of tracked changes and where the scar is. To answer the question about what determines the form and content of the spliced (post-deletion) result: In current practice it is the leading element that determines the resulting element. That is, the start tag is that of the original leading element and the end tag of the decapitated and spliced element is changed to provide a well-formed match. That appears to be a consistent practice. It is quite visible that it happens that way. It is simply how things seem to work now and in interoperability with other formats. I showed an example that would also be legal that does preserve the attributes on opposite sides of the splice, but it doesn't do anything about the elements being different. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Tuesday, October 02, 2012 01:31 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] That is *not* what is captured elsewhere. How an application "captures" the change isn't nor should it be any of our business. > THE PUZZLE > > How is this case handled in the MCT proposal? I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected. The text as saved by the application: <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> That is the text *against which* operations are expressed to record changes for acceptance/rejection by others. [ ... ] > BONUS POINTS > > In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>. <text:h text-attributes1>Consider that: </text:h> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> To anticipate interoperability questions, I think we need to define a default when deletions cross element boundaries, which typically mean a change in styles. So the question back to Dennis is: Do I have: <text:h text-attributes1>Consider that once upon a time there were three little pigs.</text:h> Or, <text:p text-attributes2>Consider that once upon a time there were three little pigs.</text:p> As the final text? [ ... ]

Dennis, It is clear that you disagree but I remain at a loss as to the source of the disagreement. If your point is ODF 1.2 does not track change tracking as proposed by MCT, right in one. If your point is that ODF 1.2 inserts elements in the markup to perform change tracking (MCT doesn't), again, right in one. If your point is that ODF 1.2 change tracking, despite being underspecified, does in fact work in some cases, once again, right in one. None of which are relevant to discussions of the basis for MCT. That is unless and until we can establish a common vocabulary and ground for discussion of MCT, we are going to talk past each other. Whether discussing the merits of MCT or other aspects of change tracking. There has been widespread agreement in the TC that the current ODF change tracking is inadequate. Robin Fontaine spent more than a year of meetings carefully documenting two complete proposals to replace ODF change tracking. Another proposal has arisen from scattered posts and presentations, which has been recommended to the TC. And we are now working on fleshing that out. Perhaps this will help (and your posts helped to provoke this comment): The difference in ODF 1.2, ECT and GCT change tracking and MCT is your starting point of view. For ODF 1.2, ECT and GCT (warning, just my opinion, others may correct), change tracking *looks forward* from the document instance as read into the application and when the file is saved, changes are recorded against the original document markup. For MCT (again, just my opinion), change tracking *looks backward* from the document instance that is being saved and records changes as operations against the document that is being saved. The results should be equivalent but how you specify them and advantages/disadvantages are quite different. Does that help? Hope you are having a great day! Patrick On 10/02/2012 04:06 PM, Dennis E. Hamilton wrote: ADDITIONAL RESPONSE To be clear, my illustrations are of a portion of a document read by a CT-implementing consumer, and the persistent form produced by that consumer. When I speak of the user action and how that producer responds, it is only meant to illustrate what is essential for the producer to arrive at the produced form of the change. In the case of the simple example, it is a deletion that crosses from the end of one paragraph-content element into the beginning of the following paragraph-content element and is implemented as a single deletion. This is a genuine use case, even though what happens at the ODF format level is simply that there is an expression of it in the persistent XML that is produced. So when I speak of what is captured somewhere, I mean in the persistent form and was not intending to imply anything about what happens internally or even what is acted upon internally. With regard to the persisted XML after the deletion in my example, there is nothing unusual in the resulting paragraph text apart from the fact that, for ODF 1.2, there will be a marker element at the point where the deletion happened. This little scar tissue contributes no content and is ignored by non-CT-aware applications. If there are no markers in the case of MCT, that makes it interesting to find when that portion of the input has a history of tracked changes and where the scar is. To answer the question about what determines the form and content of the spliced (post-deletion) result: In current practice it is the leading element that determines the resulting element. That is, the start tag is that of the original leading element and the end tag of the decapitated and spliced element is changed to provide a well-formed match. That appears to be a consistent practice. It is quite visible that it happens that way. It is simply how things seem to work now and in interoperability with other formats. I showed an example that would also be legal that does preserve the attributes on opposite sides of the splice, but it doesn't do anything about the elements being different. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Tuesday, October 02, 2012 01:31 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] That is *not* what is captured elsewhere. How an application "captures" the change isn't nor should it be any of our business. THE PUZZLE How is this case handled in the MCT proposal? I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected. The text as saved by the application: <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p> That is the text *against which* operations are expressed to record changes for acceptance/rejection by others. [ ... ] BONUS POINTS In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>. <text:h text-attributes1>Consider that: </text:h> <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p> To anticipate interoperability questions, I think we need to define a default when deletions cross element boundaries, which typically mean a change in styles. So the question back to Dennis is: Do I have: <text:h text-attributes1>Consider that once upon a time there were three little pigs.</text:h> Or, <text:p text-attributes2>Consider that once upon a time there were three little pigs.</text:p> As the final text? [ ... ] --------------------------------------------------------------------- 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 will provide a direct statement of the challenge on a new thread (not today). WHAT I'M AFTER: My reason for introducing a small case that has a grounded existence in actual implementations was to find out what the MCT equivalent is, at a comparable level of detail: How does MCT handle exactly the same situation. Specifically: Besides the markup of the as-changed specimen of a document, what other material is in the persisted document so an MCT-aware consumer can present the tracked changes and implement acceptance, rejection, and making of further arrangements. I am asking for a grounded example that shows how MCT handles the same thing or, if it doesn't, what has to happen with MCT instead? It is a very simple case and I thought this would nail down some specifics that assist in understanding and appraisal of the MCT technique. I don't think I am disagreeing about anything to do with MCT. I am in no position to do that. I do want to know what a specific (not-necessarily unique) equivalent in MCT is. Also, I don't think it matters to talk about forward and backward looking. Both ODF 1.2 and MCT produce a persistent form of the text as changed. The question is how is the tracked-change information interpreted against that text. Whatever the nomenclature on items about those transformations, there will have to be a way to present the changed text with in-line indication of additions and deletion that occurred from some previous unmodified form. That reminds me of something else though. ODF 1.0/.../1.2 include, in the <text:deletion> element, an <office:change-info> component that has a <dc:creator> element, a <dc:date> element, and an optional run of <text:p> elements providing commentary. It would be useful to know what the counterpart in MCT is and what it is associated with. In some sense, these need to align with what the user who caused the particular alteration was doing at the time. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Patrick Durusau Sent: Tuesday, October 02, 2012 17:26 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Counting issues, etc [ ... ] For ODF 1.2, ECT and GCT (warning, just my opinion, others may correct), change tracking *looks forward* from the document instance as read into the application and when the file is saved, changes are recorded against the original document markup. For MCT (again, just my opinion), change tracking *looks backward* from the document instance that is being saved and records changes as operations against the document that is being saved. The results should be equivalent but how you specify them and advantages/disadvantages are quite different. [ ... ]

I am somewhat confused about the issue of turning change tracking on/off. What happens in the following case: Consider a document with title "The Colour Purple" change tracking on change "Purple" to "Orange" change tracking off change "Orange" to "Pink" save the file Now the final form of the file contains "The Colour Pink" Which change tracking information do we expect to be stored in the file? Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

If I have a business document - as a contract - and sent the document to my business partner, I would like to know what was changed. No turning on/off of changes is desired. There is no change-tracking on/off for change-tracking systems for source code, either. To me it is a urban story of an user feature. I am traveling and will answer on Tuesday. Best regards, Svante On 30.09.2012 02:03, Andreas J. Guelzow wrote: > I am somewhat confused about the issue of turning change tracking > on/off. What happens in the following case: > > Consider a document with title "The Colour Purple" > change tracking on > change "Purple" to "Orange" > change tracking off > change "Orange" to "Pink" > save the file > > Now the final form of the file contains "The Colour Pink" > Which change tracking information do we expect to be stored in the file? > > Andreas

That's no urban legend. OpenOffice-lineage Writer and Microsoft Word all allow change-tracking to be toggled on and off without problems. (Toggling in Calc is destructive of the already-tracked changes. I don't know if that is the case for Excel.) In ODF Text documents, the <text:tracked-changes> text:track-changes setting is carried into the persistent document. I have edited documents where change-tracking was toggled off and then back on so I could correct something the software did that was not something that needed to be tracked. I have done this, for example, when producing change-tracked documents that reflect the application of Errata. If I add Editorial Notes to a document, I don't add them as tracked changes. With OpenOffice-lineage software I have to toggle sometimes because change-tracking gets something wrong (such as making unintended font changes or treating fonts as changed when they aren't, etc.) I also do it to handle changes to the embedded schema to ensure that the line-numbering is adjusted properly. LibreOffice and Apache OpenOffice have a feature (going back at least to OpenOffice.org 3.4-dev) by which one can protect the change-tracking setting. That is, it cannot be toggled without a password. This is handled in settings.xml, along with the provision to protect a complete document as read-only. The feature is on the Writer File Properties Security (bad name!) tab. But, by default, there is no such protection for ODF Text documents. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Svante Schubert Sent: Sunday, September 30, 2012 05:20 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Change tracking on/off If I have a business document - as a contract - and sent the document to my business partner, I would like to know what was changed. No turning on/off of changes is desired. There is no change-tracking on/off for change-tracking systems for source code, either. To me it is a urban story of an user feature. I am traveling and will answer on Tuesday. Best regards, Svante On 30.09.2012 02:03, Andreas J. Guelzow wrote: > I am somewhat confused about the issue of turning change tracking > on/off. What happens in the following case: > > Consider a document with title "The Colour Purple" > change tracking on > change "Purple" to "Orange" > change tracking off > change "Orange" to "Pink" > save the file > > Now the final form of the file contains "The Colour Pink" > Which change tracking information do we expect to be stored in the file? > > Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org

I agree with Dennis on this. Note also the similar issue with a CMS or SCCS where a new version is checked back in and changes are viewed: all the changes can  be found but if they cannot all be represented as change tracking then there is a similar issue of changes that are not tracked (but for a different reason). An change tracking format needs to handle this without extra work for the reading application. Robin On 30/09/2012 16:57, Dennis E. Hamilton wrote: That's no urban legend. OpenOffice-lineage Writer and Microsoft Word all allow change-tracking to be toggled on and off without problems. (Toggling in Calc is destructive of the already-tracked changes. I don't know if that is the case for Excel.) In ODF Text documents, the <text:tracked-changes> text:track-changes setting is carried into the persistent document. I have edited documents where change-tracking was toggled off and then back on so I could correct something the software did that was not something that needed to be tracked. I have done this, for example, when producing change-tracked documents that reflect the application of Errata. If I add Editorial Notes to a document, I don't add them as tracked changes. With OpenOffice-lineage software I have to toggle sometimes because change-tracking gets something wrong (such as making unintended font changes or treating fonts as changed when they aren't, etc.) I also do it to handle changes to the embedded schema to ensure that the line-numbering is adjusted properly. LibreOffice and Apache OpenOffice have a feature (going back at least to OpenOffice.org 3.4-dev) by which one can protect the change-tracking setting. That is, it cannot be toggled without a password. This is handled in settings.xml, along with the provision to protect a complete document as read-only. The feature is on the Writer File Properties Security (bad name!) tab. But, by default, there is no such protection for ODF Text documents. - Dennis
Original Message----- From: office-collab@lists.oasis-open.org [ mailto:office-collab@lists.oasis-open.org ] On Behalf Of Svante Schubert Sent: Sunday, September 30, 2012 05:20 To: office-collab@lists.oasis-open.org Subject: Re: [office-collab] Change tracking on/off If I have a business document - as a contract - and sent the document to my business partner, I would like to know what was changed. No turning on/off of changes is desired. There is no change-tracking on/off for change-tracking systems for source code, either. To me it is a urban story of an user feature. I am traveling and will answer on Tuesday. Best regards, Svante On 30.09.2012 02:03, Andreas J. Guelzow wrote: I am somewhat confused about the issue of turning change tracking on/off. What happens in the following case: Consider a document with title The Colour Purple change tracking on change Purple to Orange change tracking off change Orange to Pink save the file Now the final form of the file contains The Colour Pink Which change tracking information do we expect to be stored in the file? Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK