Hello Robin,
I am aware of the dead lines and I am sorry that I am late in this
discussion.
My absence was only caused by the decision of my former lead of
development to assign me to different tasks.
In the next days, I will be catching up with the group's work in
detail. From my current perspective a new proposal is not required.
I will work on the analysis and if necessary on the adaption of the
existing.
The key user scenario I had in mind, is when various ODF devices
(even mobiles) are in a collaboration session and one user goes
off-line over the week-end, but the user continues to work on the
document.
It would be appropriate to be able to save the off-line collab work
on the document by change tracking.
When the user comes back online, it should be able to rejoin the
collab session and become aware of potential conflicts.
I will get in contact with Tristan & John, soon.
Best regards,
Svante
On 8/1/11 1:47 PM, Robin LaFontaine wrote:
4E36923A.7020101@deltaxml.com" type="cite">
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
--
-- -----------------------------------------------------------------
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
---------------------------------------------------------------------
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
|