Svante,
OK, trying again:
When you say:
Not being saved. I can rewrite a sentence a
dozen times , in the end it is only saved the delta from the start
and the end of the session. In other words the operations are
being compressed to express the information set representing the
session delta.
What is a session?
If I save my document with tracking on and change a change (deleting
the "b" character) that was tracked, without accepting the changes:
<text:change-start
text:change-id="ct139634698526728"/>a<text:change-end
text:change-id="ct139634698526728"/>
Previously, before the save, this read:
<text:change-start
text:change-id="ct139634698526728"/>ab<text:change-end
text:change-id="ct139634698526728"/>
Now I save and *close* the file, is that a session?
<text:change-start
text:change-id="ct139634712754456"/>a<text:change-end
text:change-id="ct139634712754456"/>
IDs get changed on reload, but changing a change, is still not
captured, after save and close of file.
So far, at least in the OpenOffice implementation:
1) save does not end a session
2) save and closing document does not end a session
3) ending change tracking does not end a session
Of course, OpenOffice does not implement "to be specified operations
based CT" but that means we have to define what is meant by
"session."
I remain convinced this is possible or I would not be pushing so
hard on it.
Hope you are having a great day!
Patrick
On 09/20/2012 03:57 PM, Svante Schubert
wrote:
On 20.09.2012 15:26, Patrick Durusau
wrote:
Svante,
On 09/20/2012 08:35 AM, Svante
Schubert wrote:
Hi Patrick,
<snip>
When forward progress of the text stops? When I
stop deleting the inserted text? When the cursor has moved
off the inserted text (after deletions/additions)? Or the
cursor has left the inserted text for more than 5 seconds?
After a save?
Why shall we care? This is absolutely an implementation detail
of the application, all we have to care about is that similar
changes are able to be reflected by different set(s) of
operations, which all have in common that they have the same
information set, resulting in the end into an equal change.
For instance, instead of three operations:
- insert "a" in paragraph 1 at position 1
- insert "b" in paragraph 1 at position 2
- insert "c" in paragraph 1 at position 3
The application might as well sent one operation:
- insert "abc" in paragraph 1 at position 1
AFAIK Google Docs is pushing every change right away to the
server, like editing in a field using AJAX.
We should care because we are *not* writing a protocol for
interchange of change tracking information.
I suggest we do not invest too much energies to focus on what we
should *not* do, who has a benefit from that attitude?
Focus on what we are able to archive for our goal of
change-racking.
To allow an ODF application to undo changes made by another ODF
application has much to do of of the interchange of change
information. But perhaps we are just again at cross-purposes..
We are writing a format to track changes in a file format for
reading and presentation to a user (same or another user), post
change. On the same or a different application.
What is meant by: "..resulting in the end of an equal change?"
That the state of the document is the same.
I perform the following operations:
- insert "a" in paragraph 1 at position 1
- insert "b" in paragraph 1 at position 2
- insert "c" in paragraph 1 at position 3
I move off that changed text and perform changes elsewhere.
I return to the abc text, which shows "change" in my
interface and:
4. delete "c" in paragraph 1 at position 3
Question: Is that reflected in the *markup syntax* that is
saved as part of the document?
Not being saved. I can rewrite a sentence a dozen times , in the
end it is only saved the delta from the start and the end of the
session. In other words the operations are being compressed to
express the information set representing the session delta.
Here is what I get with the latest version of OpenOffice:
<text:change-start
text:change-id="ct139634698526728"/>ab<text:change-end
text:change-id="ct139634698526728"/>
The rest of the changes tracking:
def in paragraph 2 at positions 1, 2, 3
ghi in paragraph 3 at positions 1, 2, 3
I conclude that changes to changes are not tracked in
OpenOffice.
Sure.
That could be a *serious* failing if we are tracking changes
by authors and a subsequent author can change my change and it
still shows up as my change, albeit not as I changed it.
No problem as far as I see...
Hope you are having a great day!
Same to you,
Svante
Patrick
Changing the position pointer (start or end) may
be part of a definition of change but it is a fairly crude
one.
Only if the position pointer is part of the document state to
be changes, AFAIK OOo is saving it into the settings.xml
properties.
Otherwise I refer to the beginning of this mail, a change is
reflected by an operation call upon the document.
Hope you are having a great day!
Patrick
Hope you are having a great day as well!
Svante
On 09/20/2012 05:49 AM, Svante Schubert wrote:
Hi Patrick,
On 19.09.2012 17:04, Patrick Durusau wrote:
Svante,
On 09/19/2012 08:35 AM, Svante Schubert wrote:
Hi Patrick,
<snip>
That is at what time does the
state of the text become "fixed" so that
change tracking is engaged again?
With "fixed" you might as well think about a
compression/condensation of
operations. For example, if someone inserts a word and
deletes it again,
it will not occur in the CT, although there had been
two operations.
That was my question.
You are presuming a model that does not track changes to
changes.
Might be philosophical, as every operation creates a new
independent
document state. Therefore two (or more) sequential
operations changing
the same data, could be interpreted either as two (or
more) independent
changes of the document state or as a change of a change.
After realizing both views are equivalent it is much
easier to work
solely with the prior model, where each change is
independent and
movable along the sequence of operations (presuming to do
the required
OT adaption during movement, i.e. whenever passing a
create/delete
operation that influence the position of the moving
operation
de/increase the position integer).
Which is one presumption but
perhaps not the one that the TC desires
to make.
The TC is likely to favor the easiest and efficient model
being offered.
Can think of
compression/condensation of operations but that means
the
CT syntax has to record multiple changes, say make bold
and italic
instead of separate operations of bold, then italic (on
the same text).
From a abstract high level view, changing the style on
text is nothing
more than an change of properties on a sequence of the
document. Someone
might change a single property or multiple properties.
Latter might be
done via operations by either passing all properties along
or defining a
set beforehand. Someone might even have the vision that
some style sets
are being defined before the operations occurs (to follow
our convention
over configuration approach), either within the document
(as a given
style set) or preferable within the ODF specification, by
"style blends"
from the application vendors. For instance, the "heading
1" style set
might be defined before hand, instead of passing the
styles for every
document being opened.
Various compressions are thinkable, all they have to have
in common is
to keep the information set equivalent.
And, it means we have to define
when compression/condensation occurs
and how it is recorded in syntax.
Uncertain yet, if we have to be necessarily such strict.
We definitely
have to define what operations are equivalent. We could
even come up
with a normalized form of operations (the most efficient
form of
operations to be exchanged).
Not objecting to your answer but
it leaves out a lot of detail. ;-)
Sure, just wanted to keep the mail short ;)
Hope you are having a great day!
Patrick
Hope you are having a great day as well!
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org
--
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
|