a) There is a reason why the changes are left where
they are in GCT: there is one source but perhaps more than one
destination (cut, paste, paste) so it would probably be annoying
to have all the changes everywhere. Simpler and clearer the way it
is defined, I believe.
b) I would say no! At least that is my opinion. How do you
distinguish between one word and a whole paragraph to track this?
As for delayed cut/paste... CT is complex enough without that!
c) I guess a user could use it that way, but it was not the
original intention.
On 20/06/2011 08:48, monkeyiq wrote:
1308556102.6430.71.camel@alkid.localdomain"
type="cite">
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>
--
-- -----------------------------------------------------------------
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
|