Just a quick note to make sure the use of “unchanged” in my original text didn’t confuse anyone into thinking there was more to it than intended. I almost
get the impression there was an assumption of some sort of stateful storage representing “changedness”. I used this simply to identify a user moving a block of text (and not altering the contents, which would show up as a separate insert/delete change).
With the current insertion/deletion model, a user can’t tell whether an insertion and a deletion are related as a pair reflecting a piece of content that was simply moved. Nor can a user tell whether such a pair has had the content fiddled with, since it
all shows up as a blob of deleted text and a brand new insertion (the deleted text and inserted text need to be read and compared).
John
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org]
On Behalf Of Patrick Durusau
Sent: Tuesday, September 11, 2012 2:42 PM
To: office-collab@lists.oasis-open.org
Subject: [office-collab] Move Content - Discussion Target - 26 September 2012
Greetings!
The first issue from the ECT proposal (1),
Move Content:
ODF currently handles this case as two separate changes, an insertion and a deletion. We propose introducing move-specific elements so applications can show the change to users as a single move of unchanged
content. It may be important for a user to understand that a block of text was moved unchanged. There is currently no way for a user to know that a block of inserted text is the same as a block of deleted text without manually comparing the contents.
There are at least three separate use cases/requirements:
(a) Move content - Which content? The examples seem to presume <text:p>content</text:p> but I might want to move a graphic, or cell content.
That is a very large and opened ended question so I will be preparing a check list of elements that can contain "content" or that can be moved as though they were content.
(b) What is meant by "unchanged content?" I can move a header, unchanged in its text content but upon repositioning, it has a new number. Is it still "unchanged?"
(c) Signaling mechanisms: Since we are talking about a component model, shouldn't we use that model to address both the prior and present locations of unchanged content?
That is:
Starting markup:
<text:p>Paragraph
one.</text:p>
<text:p>Paragraph
two.</text:p>
<text:p>Paragraph
three.</text:p>
<text:p>Paragraph
four.</text:p>
Ending markup:
<text:p>Paragraph
two.</text:p>
<text:p>Paragraph
four.</text:p>
<text:p>Paragraph
one.</text:p>
<text:p>Paragraph
three.</text:p>
The delete operation for <text:p>paragraph one.</text:p> records its original location (this is always true)
The add operation for <text:p>paragraph one</text:p> records its insertion location (also always true) but also records its prior location.
Will it be sufficient if it always records only the prior location?
Seems to me it would be because the operations are performed in order.
(d) BTW, when do we determine "unchanged" or not? I may copy text from on location to another (as above) and some time later, with intervening changes, change something in the paragraph.
When it is copied, at that point it is always unchanged. Do we really want to set a marker that no changes have happened at that point?
Or, would it be better to have the insert operation have the back pointer to the original location and if there are no more edits to the content of that component at the insertion point, then it is by default "unchanged" from its prior location? All the application
need do is check for the move and whether there are any changes to that target.
That sounds cleaner to me than trying to set an arbitrary point for determination of "changedness." (On load the app will know if there are additional changes that follow at the spot of insertion.)
Thoughts?
Hope everyone is having a great day!
Patrick
(1)
https://www.oasis-open.org/committees/download.php/41699/extended-ct-proposal.odt (If I cite a document you can't download/view without logging in, let me know.)
PS: Feel free to suggest JIRA style text for this issue or any of its sub-parts.
--
Patrick Durusau
patrick@durusau.net
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau