OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-collab] Counting issues, etc


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]