office-collab message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office-collab] Multiple changes
- From: robert_weir@us.ibm.com
- To: Patrick Durusau <patrick@durusau.net>
- Date: Thu, 20 Sep 2012 17:55:42 -0400
<office-collab@lists.oasis-open.org> wrote on 09/20/2012
04:41:50 PM:
>
> 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?
>
What you have is an initial document model A, and
a modified document model A'. The change tracking problem is defining a
vocabulary for specifying set of operations on document A that will transform
it into document A', for all possible A' that may be derived from A via
editing operations. (And yes, we'll need to enumerate those editing
operations).
Although it is possible for a pathological editor
to specify the transformation of "x" -> "y" as first
inserting "z", then deleting "z" and appending "y",
I'm not sure we need to forbid this. So long is the transformation
yields the correct end state, we could allow implementation-dependent optimizations
for reducing the "edit distance" from A to A'. But there
might be practical constraints in any given implementation. Perhaps
an editor can coalesce multiple edits to the same <p> but not handle
this as well for cut & paste operations between paragraphs. Requiring
perfection here would require an implementation to store an arbitrarily
long stack of editing operations, something I don't think we want to require.
> 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:
> 1. insert "a" in paragraph 1 at position
1
> 2. insert "b" in paragraph 1 at position
2
> 3. insert "c" in paragraph 1 at position
3
> The application might as well sent one operation:
> 1. 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:
> 1. insert "a" in paragraph 1 at position
1
> 2. insert "b" in paragraph 1 at position
2
> 3. 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]