Svante,
Why count characters on attributes?
Some attributes have defined values.
Some accept user defined strings.
Are you saying count characters on both?
What do we gain by counting characters in attribute values?
Considering that we can only replace some attribute values.
Hope you are having a great week!
Patrick
PS: No problem with counting characters, assuming we define it
properly, but only on PCDATA contained by elements (ne components).
On 09/12/2012 03:19 PM, Svante Schubert
wrote:
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
--
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
|