Hi Peter,
Very good work!
There are some cases that should/might be resolved in your list of
examples.
- Identification in the ODF application model and ODF XML is
accomplished by their position. The Merge mechanism based on
operational transformation (OT) is based upon it. Therefore a
second id is redundant and dangerous:
(id = generic ID number to identify nodes in the xml)
- Similar as above the identification is always the position.
Some names in-between must be omitted. Let me explain:
- You and I are working in collaboration on a document with
1 million paragraphs and I am changing the background color
of the last paragraph to red. In former times the change was
tracked by XML in the content.xml by doing the "approach of
saving the a before/after status XML". Now it is possible by
referencing the position to sent only the change and the
position of the 1millon th paragraph.
- Let me explain OT. I am working on the 3rd Paragraph, but
you insert a new 2nd paragraph. I still want to work on the
same paragraph, but if we "commit" your change before mine
(similar to doing a commit to a decentralized git
repository), I will have to adjust my adoption on the 3rd
paragraph to become the fourth.
- One way to do change-tracking/merging is to think of a
list/stack of operation, like a stack of cards. Every time
an operation is "commited" to the document, the operation is
placed on top of the others on the top of the
"card"/operation deck.
It is like the top is the last and is dependent of the
actions of the cards below it. To undo a change, you need to
remove a card/operation from the card deck, but only the
last (on top) can be surely be removed without harm, as we
know that nothing is depending on it. Therefore any other
card within the card deck have to be moved to the top. This
can be done for instance by changing the position of the
card/operation to be removed with its card on top. When
doing so, it is like changing the time history. The prior
top card, which was executed originally later/after our card
we want to move up, is now done prior, when we exchange the
cards. But when the upper card is a deletion/insertion of a
component, which is before/ahead of the existing (in other
words is influencing its position) the position has to be
adopted.
Example. I change the 3rd paragraph background color to red,
afterwards on top is the insertion of a new 2nd paragraph.
If we switch those, the top card is now the background color
applying to the fourth paragraph. :)
- Last example: If I sent all collaboration partners an
operation telling them that I have inserted the table
"svante007" they have not the faintest idea, where this
table have to placed within our shared document. Right?
- @5 you added (me=moved end, ms=moved start), how about de
& ds for destination or even more verbose wording?
- @8/9 May I have the example document with the paragraph
break?
- @15 I have to talk to Oliver-Rainer Wittmann, if we can rely
on the image name/path (i guess we should). Likely we save the
image within the /changes directory to be able to restore it,
when necessary.
- @21 No need for an extra row position parameter, it is just
a position similar to a text position. For instance the 2nd
row of the a table being the first component would be "/1/2".
- @23/24 When it comes to columns or cell-ranges, I would
suggest to use cell ranges in general. In general I find it
handy to use all ODF Table handling by the split into two
algorithms. One is taking care of the selection, the other
taking care of the adoption/change. The first could be reused
and is providing the second each element of the selection. By
doing so, I was able to traverse the table only once and avoid
a lot of code duplications.
Happy Easter!
Svante
PS: As written on the TC list, I would like to move the discussion
on the SC Collaboration list - as this SC was created to separate
discussions on this specific functionality from the TC.
Still thank you very much for your work.
Am 10.04.2014 11:49, schrieb Peter Rakyta:
Dear
TC members!
As you might know, I develop an extension implementing the merge
enabled change tracking proposed by Svante. Recently I have made
further progress in the development. However I would like to
address several questions in order to bring closer the
specification and implementation.
-- I have uploaded an odt
(https://www.oasis-open.org/committees/document.php?document_id=52714&wg_abbrev=office)
containing the currently supported change types with simple user
cases of the related xml tags in the undo.xml. I would like to ask
you to revise these tags. Regarding style changes I kept the
possibility of representing them explicitly in the xml, since
automatic style names are still unreachable through the UNO, and
the user-generated styles are not enough to thoroughly track style
changes. (In the linked odt both bold/italic textparts correspond
to the same "text body" style.) Hence I suggest to keep this
possibility also in the standard. What do you think?
-- I think in order to get usable change tracking system, we need
also to export data on the author, creation time, and other
metadata (like a comment). May be these data should be also a part
of the specification to ensure different implementations would
handle these data the same way. What do you think? Currently my
extension makes revisions of a document, means, that particular
OTs (changes) are grouped under changesets (like an SVN). (An
example for the XML representation of a changeset is also shown in
the linked odt.)
Best Regards,
Peter
---------------------------------------------------------------------
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
|