Jos,
I have more experience of Change Tracking (CT) than real-time
collaborative editing (RTCE) but I have always understood them to be
different problems. That said, they are related and I am OK for RTCE to
be taken into account in the work of the SC. I am in agreement with you
that it should not be a requirement that the RTCE protocol problem is
solved, rather that RTCE be considered in the CT solution.
Robin
Jos van den Oever wrote:
201011081728.01292.jos@vandenoever.info"
type="cite">
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
editing.
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.
Cheers,
Jos
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
|