Svante,
Thank you for this comment on the approach to change tracking,
taking into account collaborative editing.
We started in this subcommittee at the end of last year with a
single proposal, the GCT. In March a second proposal was tabled
and since then we have been considering how these two proposals
relate to one another, and their relative merits.
In order to progress the work of the committee, we did set a
deadline for new proposals and we are beyond that now. However,
that does not mean that we cannot consider the impact of what you
are saying on our current work. It may be that there is a way to
adjust what we are doing to cater for collaborative editing in
some way, based on the work that you reference.
Therefore it would be very interesting to understand your view on
how the work that you reference could be related to one or both of
the current proposals. There may be a way of directly relating the
transformations to one or other of the current proposals, or it
may be that some minor modification would make the relationship
more direct.
Subject to the opinion of others within this group, I would
therefore ask you to comment on the two existing proposals in the
light of your needs in terms of collaborative editing.
You might like to consider for each proposal:
1. Is it possible to convert this CT representation into a wave
transformation?
- How difficult would it be?
- Would any minor change make it easier?
2. Similarly, is it possible to convert wave transformations into
this CT representation?
- How difficult would it be?
- Would any minor change make it easier?
This would be a very useful contribution to our work. I am sure
Tristan and John would help/comment as needed.
Best regards,
Robin
On 01/08/2011 02:51, Svante Schubert wrote:
Hi,
I am new to the SC mailing list as an active member.
But instead of commenting right away on one of our current
proposals, I would try to share some experience gained by working
on collaboration for Oracle's Cloud Office.
Dependencies of Change-Tracking
The implementor of a new modern ODF office suite, which supports
change-tracking, will recognize several office functionalities
that work very closely together:
- Versioning
- Change tracking
- Undo/redo
- Collaboration with other users
There is a relationship between the items above. Roughly said: One
item bundles multiple items listed directly below. More precisely:
- One version contains several changes by one or more users
- One change contains one or more undo/redo changes of one ODF
component by a single user. Removing information undesired by
the common user (e.g. it is irrelevant in what order the text
of a paragraph has been added)
NOTE: The ODF component is described in the presentation I
mentioned earlier on the TC mailing list [1].
- One undo/redo action might be a wired change event to other
ODF clients
(again there is usually a compression of information as text
changed by undo/redo is in general not altered on character
basis, but on larger granularity, e.g. words are
undone/redone)
Potential Change-Tracking Requirement
From the above, our SC is currently focusing on serializing
changes and postponed the run-time collaboration feature, as
change-tracking is most important to our users. On the other hand
when selecting the best change-tracking proposal we should as well
have an eye on its interoperability with the upcoming
collaboration feature otherwise we are loosing great potential for
ODF applications:
For example, imagine full interoperability between change-tracking
and collaboration. In this case it would be to map the
change-tracking changes to a queue of collaboration events and
vice versa. A user might than be able to apply document changes to
other documents and save collaboration directly as standardized
changes. The example above is a feature that can be taken as
potential requirement for any change-tracking proposal.
Potential Change-Tracking Feature
The following example shows a potential change-tracking feature
that is only enabled when doing a certain kind of collaboration.
Let me therefore take you a step further to common collaboration
design to show you how collaboration features might influence the
serialization of change-tracking.
User conflicts caused during collaboration are elegantly solved by
the Operational Transformation (OT) approach [2] (OT is currently
being used by Google's Web Office).
Some explaining words on Operational Transformation (OT). The OT
approach maps the editing of a document to event calls. In OT
theory even a complete document might be mapped to a queue of
event calls, creating the document by events starting from
scratch.
In OT the event is called operation and the transformation (the T
from OT) occurs when an operation has to be adapted as a different
operation happened earlier influencing it.
For example, there is a table operation to insert a column at
position 3, but someone else has already inserted a column at
position 2, the table operation therefore has to be transformed to
insert the table at position 4 instead of 3, as the original
document was changed earlier.
Now the nice side-effect: this transformation can not only be used
for collaboration, but as well to move an operation (or a grouped
set of operations) in the time-line of the queue.
Let me give a real-world example to show the potential:
Imagine you have to work on a version for the ODF specification.
Editing directly on the ODF specification, changing what is
required from a task in our OASIS bug-tracker and grouping those
changes to be related to this certain bug task.
When all changes for the version are completed, they are embraced
to a new document version.
Now imagine the case where the deadline for the version arrives,
but some issue is again under discussion. It was decided that the
changes of that issue should not be part of that version, but
still not be deleted as later still required. As the changes are
only operations in a time-ordered queue they can be moved to the
end of the queue, applying operational transformation when
necessary. Moving the undesired change out of the version range.
To summarize:
Implementors do not care much about the implementation detail of
the serialization of ODF change-tracking to ODF XML. But
implementors do care very much to be able to map every single
change to operations as used in collaboration to allow innovative
ODF implementations.
Best regards,
Svante
[1] http://lists.oasis-open.org/archives/office/201107/msg00026.html
[2] http://www.waveprotocol.org/whitepapers/operational-transform
--
Svante
Schubert | ODF Standardization
Phone: +49 40 23646 965
Oracle Office
GBU
ORACLE
Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097
Hamburg
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande,
Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen,
Alexander van der Ven
|
Oracle is
committed to developing practices and products
that help protect the environment
|
--
-- -----------------------------------------------------------------
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
|