RE: [office-collab] Counting issues, etc

[John Haug <johnhaug@exchange.microsoft.com>]

What you describe seems to me to be more about my second point ("Further,...").  To preserve the ability for an app that doesn't support CT to display the doc "as though all changes have been accepted".  I reviewed the presentation again and I may have been confusing the undo.xml / redo.xml thing.  If the deleted text is stored outside the content.xml and available for restoration, and if added text is stored in the content.xml, then we're OK on display.

But I'm still not convinced we're OK in cases where a doc is shared among a mix of applications that do and don't support CT.  Changes made in the apps that don't support CT will change the content and thus the relative references.  Assuming (dangerously) for a moment that I understand the undo.xml and referencing properly, how do we know, for example, that 

<undo>
  <del type=”text” s="/1/12" e="/1/17" />
</undo>

means I added a specific sentence in paragraph one between what was the first and second sentences if the non-CT app makes a change earlier in that paragraph?

Start:
Hello world. Lorem ipsum.

Tracked change (app 1 - understands CT, CT enabled):
Hello world. Foo. Lorem ipsum.

Untracked change (app 2 - does not understand CT):
Bar. Hello world. Foo. Lorem ipsum.

That doc sent back to app 1 will see <del type=”text” s="/1/12" e="/1/17" /> and think that "orld." was inserted, not " Foo." because app 2 didn't recalculate the /1/12 and /1/17 references when it wrote out the file.  Right?

John

-----Original Message-----
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Patrick Durusau
Sent: Monday, October 01, 2012 2:21 PM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Counting issues, etc

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


---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org