OpenDocument - Adv Document Collab SC

Please find the IRC log of today's meeting below. Our next meeting will be next year on the 26th of February. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=02&day=26&hour=15&min=30&sec=0&p1=179&p2=37&p3=136&p4=234&iv=1800 https://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=36616 The teleconference login data for next call will be found in the OASIS calendar event (URL above). Attendees: Friedrich, John, Jos, Oliver, Peter, Svante [16:30]  Svante Schubert: Hi everyone! [16:33]  Svante Schubert: Our next call will be in two weeks: https://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=36616 [16:33]  Oliver-Rainer Wittmann1: Will be a couple of minutes later - conflicting meeting [16:34]  Svante Schubert: okay, Oliver [16:34]  Jos van den Oever: hi guys [16:35]  Svante Schubert: Once again the FOSDEM URL of the talks - https://fosdem.org/2014/schedule/track/open_document_editors/ [16:35]  Svante Schubert: This was my related talk - https://fosdem.org/2014/schedule/event/real_time_compatible_odf_change_tracking/ [16:39]  Svante Schubert: My second talk - https://fosdem.org/2014/schedule/event/ox_documents/ [16:39]  Oliver-Rainer Wittmann: dailing in now [16:39]  Svante Schubert: On page 2 of the slides is the architecture - https://fosdem.org/2014/schedule/event/ox_documents/attachments/slides/426/export/events/attachments/ox_documents/slides/426/svante_schubert_3_ox_documents.pdf [16:39]  Svante Schubert: OX Text is using purely ODF (OOXML) operations [16:40]  anonymous morphed into Friedirch W. H. Kossebau [16:41]  Svante Schubert: Jos and I thought about putting our Web Offices based on operations together and translate the different (yet proprietary) operations on the fly [16:43]  Svante Schubert: Because we have to define the changes on the ODF XML [16:43]  Friedirch W. H. Kossebau morphed into Friedrich W. H. Kossebau [16:43]  Svante Schubert: we might want to put types on different XML elements [16:43]  Svante Schubert: like office:body is boilerplate [16:44]  Svante Schubert: text:span is a (text) selection [16:44]  Svante Schubert: table:table or text is a start element of a component [16:45]  Svante Schubert: There are sometimes problems when adding a component to the component tree [16:45]  Jos van den Oever: in webodf, the operations do not specifically mention the odf elements [16:45]  Jos van den Oever: only on styling do we have an explicit link [16:46]  Svante Schubert: I need the ODF XML for the specification [16:46]  Svante Schubert: it is like you load a document, do a change and save it [16:46]  Jos van den Oever: sure in the spec we'll need to explain the effect on an odf [16:46]  Svante Schubert: do it change == applying an operation [16:46]  Jos van den Oever: odf -> op -> odf [16:46]  Svante Schubert: Like a component parent is a cell, the child is a paragraph, but there are list elements around [16:47]  Jos van den Oever: btw, peter, congrats on your calligra based tablet app for android [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 wihtin the list or not? [16:49]  Svante Schubert: We have to define it.. [16:50]  Svante Schubert: It is easier to start with styles applied to characters within a paragraph. [16:50]  Svante Schubert: Editor behavior: The style comes from the prior character only for the first character it is taken from the second character. [16:53]  Svante Schubert: Than we have to differ between template styles and automatic styles [16:53]  Svante Schubert: And of course paragraph styles (their next style) and character/text styles [16:54]  Peter Rakyta- MultiRacio Ltd.: Jos van den Oever: thank [16:54]  Svante Schubert: It is the question if we should make this above editor behavior implicit in the standard or make explicit styled operations. [16:56]  Svante Schubert: I started to analyze the pro/con in terms of OT and will publish results on the mailinglist [17:00]  Svante Schubert: Peter: Tells a little about their new Andoid based Calligra office, which is not providing collabration. The sources should be someone, no link atm. [17:01]  Svante Schubert: bye [17:01]  Oliver-Rainer Wittmann: bye

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. 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. 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. 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)? Hear you soon, Svante

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