IRC log from today's meeting - 2015-02-11

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

Our next meeting will be on the 25th of February:
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2015&month=02&day=25&hour=15&min=30&sec=0&p1=179&p2=37&p3=136&p4=234&iv=1800

The teleconference login data for next call will be found in the OASIS calendar event:
https://www.oasis-open.org/committees/event.php?event_id=36637

Short summary, as we have not consistently written protocol during discussions:

Andras mentioned his concerned of MCT due to the slow progress in the TC in the past and the problems he expects LibreOffice team might have implementing it.
I responded there was indeed little progress in specification due to a lack of resources, but meanwhile I had worked for Open-XChange convinced them of this approach for their new browser based office and there are three operation based implementations for ODF, OOXML and HTML, which source repositories are public.

Peter mentioned his LibreOffice MCT Extension prototype in Python and did not share Andras concern.

During the call I pointed out three reasons for the explicit definition of changes aside the main content as MCT defines it:

1. Changes will be the base for collaborative (real-time) editing of ODF across applications for the future. The definition of repeated user changes (adding, delete, modifying) of typical entities (image, paragraph, text, tables, etc.) abstract change details to easy exchangeable symbols. Separating the document from the change, easing merge of changes as the complexity does not relate with the size of the document, only the amount of changes.
   
2. Conformance testing of ODF applications. Only if ODF specifies changes, applications can be tested against them: Loading a document, applying defined changes, saving and comparing with reference. A centralized (conformance) testing will help everyone working with ODF and might become a subject of public funding.
   
3. The existing change-tracking is saving away the previous state of an area before editing as a XML black box. This state will be inserted back during a reject. This becomes problematic when there is a sequence of overlapping changes and not the last are being rejected. This will become even important with metadata in the future.
   

Further discussion took place. I would welcome further discussion on the mailing list. Likely I will not be able to respond before next week.

Here the IRC protocol:

Attendees:
Patrick Durusau, Peter Rakyta, John Haug, Oliver-Rainer Wittmann, Andras Timar, Svante Schubert

[16:30] Svante Schubert: Hello Andras

[16:30] Andras Timar: Hello Svante

[16:31] Svante Schubert: Have you seen the LibreOffice extension based on python code that Peter from MultiRacio has created to test operation based change tracking?

[16:32] Svante Schubert: Hi Peter

[16:32] Peter Rakyta: Hi there!

[16:32] Svante Schubert: Michael Stahl told me yesterday LibreOffice is supporting Python3

[16:34] Svante Schubert: Just told Peter he should put his extension into an issuetracker and clear the license for LibreOffice

[16:35] Svante Schubert: Andras will you join the call?

[16:38] Oliver-Rainer Wittmann: joining

[16:57] John Haug: is the call still working? mine has been silent for about 30 seconds

[16:58] Peter Rakyta: the call is still on-going

[16:58] John Haug: hm

[17:04] Svante Schubert: I have asked Peter to give feed-back to Andras and the libreoffice developers about the experience of the MCT LibreOffice extension

[17:04] Svante Schubert: He is willing to do so

[17:05] Svante Schubert: He thinks it is applicable and the MCT approach is more powerful than the other proposals

[17:06] Svante Schubert: Andras: Is questioning the performance of the extension

[17:07] Svante Schubert: Peter: Like the encapsulation of changes in a abstracted list, instead of merging the changes into the XML content

[17:07] Svante Schubert: Peter: Has not tested large documents, but do not see any reasons that there are problems.

[17:09] Svante Schubert: bye bye

[17:09] Oliver-Rainer Wittmann: bye

Attachment: signature.asc
Description: OpenPGP digital signature