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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Another example of relationship of change tracking to real-timecollaborative editing and other scenarios

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, 

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.


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