Copy and paste semantics

[monkeyiq <monkeyiq@gmail.com>]

Hi,
  I stumbled on an interesting choice during copy and paste when editing a document with change tracking. The core question is what to do about the change tracking history information from the source selection. Currently, the GCT specifies that during a cut and paste (move) the old content is left in place with a move-id added and marked as deleted, and the new content is inserted without history but a move-idref to the old content in order to retain history.

  I can see in this situation why the GCT is as it is. A move of content either has to duplicate the history in the new location or, as specified, one can "start fresh" by leaving the old content in it's original location, marking it deleted, and linking to it. An alternate which comes to mind would be doing the reverse of what is specified, inserting a marker where the original content *was* and moving everything to the new location, including the entire change history. Though there are likely some dragons to that design that I've not considered.

  As specified in the GCT, there is a slight tinge of the ECT buckets. This is because when a cut and paste is done, we create an old fragment with the history up to that point and link the pasted content to that old history location. Things are not as drastic as with ECT buckets because the GCT only does this during a content move rather than during content editing. It does however allow for a possible chain of links to deleted content when some content is cut and pasted multiple times during the course of an edit history.

  From what I see, the GCT doesn't include provision for tracking copy and paste, only moves. For small copy/pastes this is a bit of a mute point, say the copy of a single word or short phrase. But if one copies a whole paragraph or larger item then perhaps the document should have a way to track and reflect that, because the user didn't really come up with the content itself. For larger blocks, it might also come to be that the original paragraph is deleted at a later stage, making for a delayed cut/paste edit.


So the main points are:

a) should we reverse things so that a move leaves just a marker in the original location and moves the entire source content over to the destination. If we look at this, what unforeseen implications are there?

b) do we want to track copy and paste too?

c) if we retain the "move" like linking, do we want to make it general purpose? For example one might apply it to a whole paragraph or selection in order to simplify the markup for the paragraph at a changeid. This is sort of like the epoch idea where the user might decide to apply this "cleanup" to a whole chapter etc to simplify whole document I/O when that chapter is no longer being scrutinized. ie, the  changes in the chapter are all "accepted" and any further edits would consider the current content as the original baseline. Though with the GCT "move" linking, the old content & history is still available too if desired.


  And now some background and references from my investigations...

I found this while working on explicit start and end of paragraph delete marking. Consider a document in change-id=5, the user selects from the middle of para2 through to the middle of para4 and hits delete. The internal document model is to be updated to record that the end of para2 is deleted, the start and end of para3 are deleted and that the start of para4 is deleted (all in id=5). This way, when writing ODT+GCT the application can merge p2-p4 in a single delta:merge element to produce something like the following. In this case because the end of para2 is deleted a delta:merge is begun, because para3 has its start and end deleted it is intermediate content, and because only the start of para4 is deleted it forms the end of the trailing content.

   <text:p ...>para1</text:p>
   <text:p delta:insertion-change-idref="1" >pa
   <delta:merge delta:removal-change-idref="5">
      <delta:leading-partial-content>ra2</delta:leading-partial-content>
      <delta:intermediate-content>
         <text:p delta:insertion-change-idref="1" >para3</text:p>
      </delta:intermediate-content>
      <delta:trailing-partial-content>
         <text:p text:style-name="Normal" delta:insertion-change-idref="1" >
           <delta:removed-content delta:removal-change-idref="5">pa</delta:removed-content>
         </text:p>
      </delta:trailing-partial-content>
   </delta:merge>
   <delta:inserted-text-start delta:inserted-text-id="ctid-2" delta:insertion-change-idref="1"/>ra4<delta:inserted-text-end delta:inserted-text-idref="ctid-2"/>
   </text:p>

This is all well and good but some cases are raised when this block of ODT is further operated on with copy and paste. Consider what happens when the user selects "para2...para4" in the document and copies it, then pastes to anther location.

Looking at the GCT one finds the following, ending up at point 6.10.3 shown below.

Point 14 on page 5 of 23 of draft 4 of the GCT:
  "14... The change history of an element is not moved with the
  element. Content that has been moved from position A to position B
  can be moved again from B but it is deleted from A and so cannot be
  moved from A in a later operation."

6.10.2 Move an Element / Example
  An anchor in the old delta:removed-content element with delta:move-id="mv33"
  and a reference to it from the inserted element with delta:move-idref="mv33"

And finally 6.10.3 explicitly mentions: 
  "When content is moved, all its change history is reset, e.g. a
  move-from paragraph has the change history and the move-to has no
  history, it is as if it has been added new. "

So this would indicate that a cut and paste would result in the following, because the original ra2, para3, and par strings were all deleted during the delta:merge. As change tracking history is not deep copied, one gets the simplification shown.

<text:p delta:insertion-change-idref="6" delta:move-idref="zz5">para4</text:p>

And a copy and paste would give the following, loosing indication of where content originated.

<text:p delta:insertion-change-idref="6">para4</text:p>