Re: [office-collab] Multiple changes

[Patrick Durusau <patrick@durusau.net>]

Svante,

Just quickly.

You need to stop eliding over what you mean by "change."

From below:

> 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).

Now you imply that a change is not a change unless the "create/delete 
operation ... influence[s} the position of the ...the position integer."

Which negates the idea of tracking changes to page formatting (which we 
track now), changes styles applied to text (a requested feature), none 
of which impact the position integer.

For that matter, it includes changes made as I insert "new" text because 
the end position pointer is expanding as I type and decreases if I 
delete part of the inserted text, before some designation of "state."

When does the insertion/deletion of *new* text become fixed with regard 
to OT change tracking? 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?

Changing the position pointer (start or end) may be part of a definition 
of change but it is a fairly crude one.

Hope you are having a great day!

Patrick


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