Re: [office] Another example of relationship of change tracking to real-time collaborative editing and other scenarios

[Jos van den Oever <jos@vandenoever.info>]

On Sunday, November 07, 2010 17:00:45 pm robert_weir@us.ibm.com wrote:
> I am in a standard desktop word processor.  I copy a selection from one
> document and paste it into another document.  The section I copy and paste
> has content, styles, metadata and possibly extensions.  From a markup
> perspective we could change track this as individual changes to the
> destination document,  one addition to content, one addition (potentially
> -- it could be using an existing named style) to styles, one addition to
> metadata, etc.  This would be "correct" in that it models perfectly the
> complete set of of changes made to the document.
> 
> However, from the user perspective, this is not an optimal solution, since
> the user expects to treat this complete bundle of changes as an atomic
> unit at the change tracking level, and to be able to apply or reject these
> changes as a whole.  It would be incorrect to the user if this showed up
> as 3 or 4 changes that could be independently accepted or rejected.  (This
> directly parallels what one would expect from the undo stack._
> 
> So change tracking will naturally need to deal with how complex changes
> are bundled together into logical user-level actions.
> 
> Note that this is pretty much the same requirement for several other
> document collaboration scenarios, including:
> 
> 1) Cut & Paste between documents, obviously.
> 
> 2) Real-time collaborative editing, e.g., changes I make to a document are
> reflected to another word processor instance over the network, e.g,
> AbiCollab.
> 
> 3) Asynchronous multi-user editing, where a document is split into
> multiple fragments, edited and then later merged together.
> 
> There are probably other similar scenarios.  But there is a common thread
> here: how do we associate content, styles, metadata and extensions at the
> sub-document level, e.g., at the level of a selection.  That is why I
> think we need to consider this set of problems together, although we may
> only have an immediate interest in change tracking.

I would like to make the observation that any description of a change made to 
a document is only meaningful if the complete document is present for 
reference. While the references in an ODF document may all be perfectly 
resolved, the references in human language are often ambiguous and hard to 
resolve. For anyone to accept a change as meaningful, the person should be 
assumed to need the entire context.

Another observation: currently change tracking handles a linear history. Real-
time collaborative editing usually starts from a common point then diverges 
over small time periods and merges constantly. The merge algorithms are 
probably not of concern to the SC, but the need to visualize concurrent 
changes so that the user can make an informed opinion on how to resolve a 
conflict, is.
For archiving purposes it is also desirable to show what changes were made by 
whom when and what patches were used in the assembling of the final document. 
In other words, can the current or desired Change Tracking also do Concurrent 
Change Tracking?

Cheers,
Jos