OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office-collab] Multiple changes


Replying to this one and intentionally branching it since the subsequent replies go further afield from the discussion thus far.


[Patrick] If I don't save the text, but simply change it to bold and before saving, also underline the "text" part, is that to be two change operations or only one?

I think that's up to the app to decide (which seems to be where the later conversation went).  As long as the document format syntax provides a means to track changes, the apps are free to determine when/how to use them as makes sense within an editing session for that app's context.  The markup will be readable by any consumer.


[Svante] 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.

It could, if the app decided to track that.  A common example is changes made by different people.  I add a word, you delete it and some users would expect to see that.

The compression topic is the same as my comment above, no?  The app gets to decide which user changes are lumped into a single markup-tracked change, and as long as it has the syntax to describe that change, ODF has done its job as a markup specification.  ODF doesn't need to provide (what is essentially a runtime) mechanism for compressing individual changes.


John

-----Original Message-----
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert
Sent: Thursday, September 20, 2012 2:50 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Multiple changes

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]