Re: [office-collab] Counting issues, etc

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

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