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
