Hi Patrick,
thanks for starting this, allow me to answer just briefly below.
On 11.09.2012 23:41, Patrick Durusau wrote:
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.
A component, including its children will be moved.
A component is in general identified by its root element. Here the
paragraph component has <text:p> as its root element.
Every character/glyph is as well a component, therefore the word
"content" is represented by 7 components, being the children of the
Paragraph component.
(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?"
The order and the numbering is redundant information, which can be
created by the number of preceding headers and the numbering style.
Components are an abstraction of the XML implementation details of
ODF and should neglect such redundant information, which should be
known by the application.
(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.
We would keep the undo information to get from the ending markup to
the start markup. We would describe that the undo operation would be
"to move the third component back to the first position", as a
serialized operation to XML it could be
<move s="/3" e="/1" />
(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.)
The component is not being changed during the move operation, but
might be as well changed before or afterwards the "move".
The "move" is just a single operation in a stack/queue of operations
to the document.
Best regards,
Svante
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
|