Hi Patrick,
On 12.09.2012 20:39, Patrick Durusau wrote:
Svante,
On 09/12/2012 11:42 AM, Svante
Schubert wrote:
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.
Presumed but the examples I have seen mainly involve text.
What if an image is changed (post-move)?
Handled the same way. If there is a a text between the text it is
counted similar as the characters.
A component is in general identified by its root element. Here
the paragraph component has <text:p> as its root element.
Not a root element. See my prior post.
Component root element. See my prior post. ;)
Every character/glyph is as well a component, therefore the word
"content" is represented by 7 components, being the children of
the Paragraph component.
Well, not every character/glyph.
What if I want to change the value of an attribute? Where the
value is user defined?
The change of an attribute is usually the change of the state of a
component. The state of a component is similar to object orient
programming represented by member variables, I would suggest to name
them component properties, to distinguish them from our XML
attributes.
Do we want to support changing one or more characters do we simply
allow for delete/add in its entirety?
One or more characters, as in the example.
(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.
Understood but my question was "unchanged?" Doesn't matter how the
change happened.
I understood the requirement to be signalling the user the content
was unchanged.
What I was suggesting was implementations observe if there are any
changes to moved content. Knowing its origin and present location,
assuming we define content to not include style changes (such as
numbering), then it could so signal to the user.
It was unchanged during the move. Like you moving a block of wood
from one place to another, not changing the wood. Perhaps I do not
understood the problem.
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" />
Modulo the problems with identification and counting, this
requires the move operator.
So, what if I cut and then several change tracked operations
later, so that the numbering has changed, I want to insert the
prior copied text?
No problem, as the numbering is implicit and not part of the
operations.
Copy/Cut and Paste are GUI Operations. There will be no memory as in
cut/copy, just a move.
Therefore in your scenario the app might do a simple delete first
and exchange the delete later, when the insert has happened to a
move.
How do I bind the prior (now deleted location) to the present
location where I am pasting the text?
Two steps:
1) Move the delete to the top of the stack (being latest undo
operation). By doing so, the previous delete position might be
adjusted during movement to the latest current correct position.
2) Exchange the "delete" operation with a "move" operation
(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.
OK, so the move is a single operation. Change may happen before or
after, but not during.
Curious what you think of the delayed paste case above?
Hope you are having a great week!
Patrick
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
--
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
|