IRC log from today's meeting - 2014-02-26

[Svante Schubert <svante.schubert@gmail.com>]

Please find the IRC log of today's meeting below. 
Our next meeting will be next year on the 12th of March.
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=03&day=12&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=36617

The teleconference login data for next call will be found in the OASIS calendar event (URL above).

Attendees: John, Patrick, Oliver, Peter, Svante

[16:28] Oliver-Rainer Wittmann: hello

[16:29] Peter Rakyta- MultiRacio Ltd.: Hi Oliver

[16:32] Svante Schubert: Hi everyone

[16:32] Peter Rakyta- MultiRacio Ltd.: Hi Svante!

[16:34] Svante Schubert: Starting with our next meeting:
Our next meeting will be next year on the 12th of March, see
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=03&day=12&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=36617

[16:34] Patrick: I've got 10:31

[16:35] Svante Schubert: I have sent a mail today on the mailing list regarding our discussion from our last call:
https://lists.oasis-open.org/archives/office-collab/201402/msg00001.html

Oliver already gave a reply to it:
https://lists.oasis-open.org/archives/office-collab/201402/msg00002.html

[16:36] Svante Schubert: I agree with what Oliver had posted.

[16:36] Svante Schubert: Regarding the delete, I meant a second time pressing the delete button on the keyboard

[16:37] Oliver-Rainer Wittmann: ok - user action == 'delete'; CT operation == 'merge paragraph'

[16:37] Svante Schubert: Si/yes/yo/excactly

[16:38] Svante Schubert: Implicit and explicit will certainly have a huge impact on exchanging the operation in a queue/list.

[16:38] Svante Schubert: Implicit will make OT quite complicated, I am curious if we find sufficient benefits..

[16:39] Svante Schubert: Oliver: If we really one to define addParagraph operation with relation to its content/surrounding, it will be complicated. Ending up a lot of special cases.

[16:40] Svante Schubert: Oliver: For example, adding paragraph after a table or after a section as in this case the previous paragraph is not clear.

[16:41] Svante Schubert: Oliver: There is the ODF feature "NextStyle" on a style.

[16:41] Svante Schubert: Oliver: In general after a Heading style a Normal style is following.

[16:45] Svante Schubert: Patrick: If the application generating the paragraph style based on the next style property, the operation will "only" make the next style properties explicit

[16:45] Svante Schubert: Or in another way, the "next style" template style will be used, after a heading it is usually default/normal.

[16:46] Svante Schubert: Oliver: If we provide the properties explicitly, the applications are more independent of their application behavior. Past and future..

[16:46] Patrick: Clarification: For a paragraph following a header, next style, paragraph following a paragraph, the prior paragraph style, by application and the suggestion is that once the change is made by the application that the change operation as written, has the style explicitly included in the change notation (don't have to understand the context where the change took place).

[16:49] Svante Schubert: In OpenXchange the splitParagraph is being used to create a new paragraph, the last text style at the end of the paragraph is being used for the next one.

[16:49] Svante Schubert: On the other hand, when parsing an ODF document every text is being mapped to an addParagraph with explicit styles from my OperationProducer.

[16:50] Svante Schubert: both approaches are currently working, but when it comes to OT, I currently believe explicit is the far easier one. Examples will follow on the list.

[16:52] Svante Schubert: So splitParagraph at the end of a paragraph and insertParagraph are currently both used for creating a new paragraph.

[16:52] Oliver-Rainer Wittmann: may be it makes sense to have addParagraph operation by default with explicit props., but allow a feature 'take the props. from previous') and to let the applications assure that this feature is only used, when it make sense

[16:53] Svante Schubert: It seems splitParagraph seems imperformant as for XML I need to traverse the paragraph to the very end.

[16:54] Svante Schubert: First question: when does it makes sense. Second question: Do we really want to have to design/implementations to provide the same feature? Seems like boilerplate, redundancy to me.

[16:55] Svante Schubert: ^^ comment regarding olivers question earlier.

[16:55] Svante Schubert: Instead of adding a styling again and again a referenced style can/might be used.

[16:58] Svante Schubert: Olivers: Agress. \o/

[17:00] Svante Schubert: With implicit styles, the OT will be pretty complicated.

[17:00] Svante Schubert: Not only the position, but also the properties have to be adjusted.

[17:02] Svante Schubert: We have to add a style via an operation. All following operations can refer to the style ID.

[17:03] Svante Schubert: ^we have^we have the possitiblity already

[17:03] Svante Schubert: Oliver: OpenOffice does use the automatic style concept as well internaly.

[17:04] Svante Schubert: ^^the bundling of format properties to styles not known by the user

[17:04] Svante Schubert: I do not see any reason any longer to use an implicit style concept.

[17:05] Svante Schubert: If there are reasons comming up in the future, pls post it to the list, otherwise we stick with exlicit handling for now

[17:05] Oliver-Rainer Wittmann: I think one important CON for implicit styling is the arguement which Svante mentioned regarding re-org. of the CT operation stack

[17:05] Svante Schubert: The problem of repeating style properties can be solved by extracting those properties to an "automatic" style

[17:06] Svante Schubert: also during the compression time of the operations stack/queue/list

[17:08] Svante Schubert: Peter: Had problems with the AOO/LO implementation accessing automatic styles

[17:09] Svante Schubert: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-style_style

[17:13] Svante Schubert: IMHO there is no need to have spreadsheet and text table operations.

[17:13] Svante Schubert: we should use a subset for text table.

[17:14] Svante Schubert: There is some view like explicit creation of rows/cells/columns in text and implicit in spreadsheet.

[17:16] Svante Schubert: In the front-end of the spreadsheet, the table seems endless. You may add content anywhere and the underlying ODF XML have to expand on demand basis.

[17:17] Svante Schubert: While often the text view was to explicitly add the rows, cells desired. But the text table can be handled similar, so it is far easier (more beautiful) to handle both scenarios the same wa.y

[17:19] Oliver-Rainer Wittmann: OpenOffice Writer does not use the table:number-column-/row-repeated feature from ODF to stored tables in a compressed form, but OpenOffice Calc does

[17:21] Svante Schubert: I believe table:number-column-repeated works on columns, but not on cell (or was it vice-versa?) one of the few things MSO15 was not able to load correctly in ODF 1.2.

[17:23] Svante Schubert: byebye

[17:23] Oliver-Rainer Wittmann: bye