Re: [office-collab] Discussion from last call..

[Oliver-Rainer Wittmann <ORWITT@de.ibm.com>]

Hi,

see my comments below


Mit freundlichen Grüßen / Best regards
Oliver-Rainer Wittmann

--
Advisory Software Engineer
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland 
Beim Strohhause 17 
20097 Hamburg 
Phone: +49-40-6389-1415 
E-Mail: orwitt@de.ibm.com 
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzende
des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294 



From:      
 Svante Schubert <svante.schubert@gmail.com>
To:      
 "office-collab@lists.oasis-open.org"
<office-collab@lists.oasis-open.org>, 
Date:      
 26.02.2014 14:05
Subject:    
   [office-collab]
Discussion from last call..
Sent by:    
   <office-collab@lists.oasis-open.org>

---

> Hi everyone,
> 
> first allow me to remind you on our SC call today
and second there is
> unfinished business open from our last call:
> 
> [16:48] Svante Schubert: Oliver: Example: Document
with 4 paragraphs,
> 2nd and 3rd in a list [16:49] Svante Schubert: Oliver:
Inserting a
> 4th is a new paragraph, is it within the list or
not? [16:49] Svante
> Schubert: We have to define it..
> 
> First some comment from the bird perspective: We
have to be sure to
> distinguished the application behavior of the ODF
application in its
> GUI presented the user, which we do not specify and
the operations
> being recorded to describe the changes, which are
important to us.
> 

Yes, from my point of view it does not make sense to define
the change tracking operations on a certain behavior of a certain ODF application.
We, as representatives of the one or the other ODF application
have to be assure that the user actions in the ODF application can be expressed
by one or more change tracking operation.
That is also the reason why I proposed the feature to
group certain change tracking operations in order to represent the fact
that _one_ user action is represented by _x_ ODF change tracking operations.

> Let me give you a detailed example: First, I have
prepared the
> initial test documents: I have started a text document
once in MS
> Office 2013 (MSO15) and once in Apache OpenOffice
4.0.1 (AOO401),
> both times I have insert first a paragraph with heading
style and the
> text "ab"and a following paragraph with
normal style and text "cd".
> Afterwards I did some different hard characters formatting
on each
> paragraph.
> 
> Second, I have made a cursor selection in the GUI
from the middle of
> the first paragraph to the end of the second paragraph
and pressed
> delete. In AOO401 there is only one heading paragraph
remaining,
> while in MSO15 there are two paragraphs and it requires
a second
> delete to get to the same state.
> 
Minor remark:
I think that the second step that Svante performed in
MSO15 is a 'merge' and not a delete.

> NOTE: I have uploaded a ZIP with the before/after
test docs to our
> repository - see
> https://www.oasis-open.org/apps/org/workgroup/office-collab/document.php?document_id=52328
>
>  On operation level it makes sense that AOO401
executes two
> operations in one user action to be compatible with
a potential
> real-time collaboration with MSO15.

I think that depends on the types and the features of
the change tracking operations which we will have when we have finished
our work.
If we will have 'simple' change tracking operations we
might end up with three operations of this singe user action in AOO. Namely,
'delete content in paragraph 1', 'delete content in paragraph 2', 'merge
paragraph 1 with paragraph 2'
If we will have 'complex' change tracking operations we
might only need one. Namely, 'delete content and components incl. merging
from position 1 to position 2'

> The details of the merge we have
> discussed before on this list, see
> http://markmail.org/message/lc27t32nssfh2hz7
(and its thread)
> 
> Now let me rephrase Oliver's initial question: What
are the pro/con
> to sent a addParagraph operation with explicit properties
(e.g. list
> level) versus inheriting properties implicitly from
the previous
> paragraph? What impact would each solution have on
OT (operational
> transformation)?

Some thoughts from my side - not complete.
con for inheriting props. from previous:
- If the add paragraph operation needs to reference a
previous paragraph we need to define, what the previous paragraph is under
_all_ use cases. E.g.: add the first paragraph in a table cell, text frame,
shape, document; add a paragraph after a section, a table, ... For all
these use cases we would need to specify what the previous paragraph is
- quite hard I think.
pro for explicit props:
- All user actions which lead to an addition of a paragraph
will be more or less represented by the same set of change tracking operations.
No need to distinguish between e.g. adding a paragraph behind another paragraph
and adding a paragraph behind a heading.

Best regards, Oliver.
> 
> Hear you soon, Svante