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: Re: [office] Proposal for Advanced Document Collaboration Subcommittee

On Saturday, November 06, 2010 20:24:22 pm robert_weir@us.ibm.com wrote:
> An example::  Real-time collaborative editing needs to track changes as
> well, because it sends changes over the wire.  So it would be beneficial
> if we design change tracking in a way that this would work naturally.  One
> could, as an example, decide to store complete versions of the changed
> document, and rely on runtime intelligence of the editor to generate,
> on-the-fly the change tracks.  This would satisfy the core change tracking
> needs perfectly.  But it would not be something that one could easily use
> for real-time collaborative editing and similar scenarios.  So I'd argue
> that we want to be discussing these common technical concerns together,
> not separately, since the choice of the exact change tracking solution has
> a large impact on how some other scenarios are done, and how hard it will
> be for ODF implementations to support these and related scenarios.
> Some commonalities (not exhaustive) are:
> 1) the need to identify content at a sub-document level.
> 2) the need to identify the styles relevant to content at a sub-document
> level
> 3) the need to identify metadata relevant to content at a sub-document
> level
> 4) the need to idetify extension content relevent to content at a
> sub-document level
> 5) The need to associate content, styles, metadata and extensions at a
> sub-document level
> 6) The need to package and exchange and merge coherent sub-document
> fragments
> If these discussions no not occur together, among the same parties, then
> the overall solution will likely be needless complex and hard to
> implement.

Change tracking (CT) is very comparable to real-time collaborative editing 
(RTCE). The biggest difference from a user point of view is the time between 
edits and the possible visibility of other people's caret in your document.

Etherpad, Google Docs and Abiword and probably others have already implement 
RTCE. Yet these programs cannot collaborate amongst each other. I would like 
the subcommittee to have a scope that encompasses both forms of collaborative 

In RTCE, CT would play the role of visualizing a differences that have come 
from concurrent edits in  a document and cannot be merged by one of the merge 
algorithms. In a nutshell, CT is RTCE without the automatic merging of changes 
in live documents.

I agree that DeltaXML is certainly not the only option under consideration for 
this use case. There are two implementations of it underway and these may help 
the committee in determining if DeltaXML would fit with the desired use-cases. 
As such this subcommittee would advice or prepare information for the ODF-Next 
committee on this part of the functionality.

Tasking the SC to come up with a sanctioned protocol for RTCE now would go too 
far, but I do think the existing protocols and their compatibility with TC 
should be considered and combination scenarios made explicit in the 
recommendations of the SC so that future effort- and specification duplication 
can be avoided.


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