<div dir="ltr">Dear LibreOffice developers,<div><br></div><div>allow me to cross-post you an update from our <a href="https://tdf.github.io/odftoolkit/">TDF ODF Toolkit project</a>!</div><div><br></div><div>There will be a documentation update end of next month with following releases for 0.9.0 and 1.0.0, the latest documentation can be found <a href="https://tdf.github.io/odftoolkit/docs">here</a>.</div><div>Shortly after I aim to release a release supporting ODF 1.3.<br><br></div><div>If you are even vaguely curious, our <a href="https://tdf.github.io/odftoolkit/docs/mailing-lists.html">email dev list</a> is very low traffic.</div>Happy to answer any questions or receive feedback <a href="https://tdf.github.io/odftoolkit/docs/mailing-lists.html">at the ODF dev list</a>.<div><br></div><div>Hope you are doing well!</div><div>Svante</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>Von: <strong class="gmail_sendername" dir="auto">Svante Schubert</strong> <span dir="auto"><<a href="mailto:svante.schubert@gmail.com">svante.schubert@gmail.com</a>></span><br>Date: Do., 30. Apr. 2020 um 10:03 Uhr<br>Subject: The Future of the Simple API (and ODF Toolkit)<br>To: <<a href="mailto:dev@odftoolkit.org">dev@odftoolkit.org</a>><br></div><br><br><div dir="ltr"><div>Hi everyone,</div><div><br></div>The future of the Simple API is that it will be discontinued after 0.9.0 due to copied source code parts and the resulting inability to add the new change support.<div>Still, the very idea of a high-level API will be continued.<div><br></div><div>In the future, we should have some architecture as the following</div><div><br></div><div><div><img src="cid:ii_k9mfhp3f0" alt="archi.png" width="541" height="406"><br></div></div><div><div>Slide 16 from last year's LO presentation:<br><a href="https://libocon.org/assets/Conference/Almeria/Svante-Interoperable-Office-CollaborationwithNotes.pdf" target="_blank">https://libocon.org/assets/Conference/Almeria/Svante-Interoperable-Office-CollaborationwithNotes.pdf</a> </div><div> </div></div><div>Currently, we have unfortunately up to two to three places where the functionality of this future high-level API resides. This has to be consolidated.</div></div><div><ol><li>In the <a href="https://github.com/tdf/odftoolkit/tree/master/simple/src/main/java/org/odftoolkit/simple" target="_blank">Simple API (deprecated) </a></li><li>In the <a href="https://github.com/tdf/odftoolkit/tree/1.0.0_SNAPSHOT/odfdom/src/main/java/org/odftoolkit/odfdom/doc" target="_blank">ODFDOM doc package</a> (the origin of Simple API fork, deprecated afterwards in favour of the Simple API and now likely being enabled again)</li><li>In the <a href="https://github.com/tdf/odftoolkit/tree/1.0.0_SNAPSHOT/odfdom/src/main/java/org/odftoolkit/odfdom/changes" target="_blank">ODFDOM changes packages</a>, which embraces the functionality to 'compile' an <a href="https://github.com/tdf/odftoolkit/blob/1.0.0_SNAPSHOT/docs/docs/presentations/character-styles.odt" target="_blank">OpenDocument text file</a> into<a href="https://github.com/tdf/odftoolkit/blob/1.0.0_SNAPSHOT/docs/docs/presentations/character-styles.json" target="_blank"> an equivalent sequence of (JSON) changes</a> and allows merging of new changes back. Why are compiling an ODT into changes? Because sending documents around for collaboration is as clever as if software developer would be zipping their source code repositories and sending those instead of change commits!</li></ol><div>There is already some <a href="https://tdf.github.io/odftoolkit/docs/odfdom/operations/operations.html" target="_blank">change API documentation</a> and it will be improved for the 1.0.0 release.</div><div>The transforming concept is as follows: Transforming an ODT into the user changes creating it:</div><div><div><img src="cid:ii_k9mg3itu1" alt="changes-to-2020-04-30_0926.png" width="541" height="311"><br></div></div><div>Slide 13 (above) and 14 (below) from last year's LO presentation:<br><a href="https://libocon.org/assets/Conference/Almeria/Svante-Interoperable-Office-CollaborationwithNotes.pdf" target="_blank">https://libocon.org/assets/Conference/Almeria/Svante-Interoperable-Office-CollaborationwithNotes.pdf</a> <br></div><div>Thanks again to the <a href="https://prototypefund.de/project/documents-for-democracy/" target="_blank">PrototypeFund project who had supported this</a>!</div><div><br></div><div>And the other way around, it is a merging of new user changes back into the ODT:</div><div><div><img src="cid:ii_k9mge2ra2" alt="changes-back-2020-04-30_0925.png" width="541" height="334"></div></div></div><div>These changes are currently serialized as JSON, for instance, to be sent to a web editor such as <a href="https://www.open-xchange.com/portfolio/ox-documents/" target="_blank">OX Documents</a>.</div><div>(FYI - I implemented several years for Open-XChange this implementation in AL2 license on their fork of ODFDOM). </div><div>But changes could be serialized for other reasons, for instance in XML and being added to the ODT zip for Office change-tracking. I have suggested this approach to the OASIS TC and my approach succeded against DeltaXML and Microsoft to be implemented in ODF for change-tracking, but currently, aside of us/me nobody is implementing it yet, therefore the Subcommittee of "Advanced Document Collaboration" of OASIS - which I am chairing - is hibernating atm.</div><div><br></div><div><font size="4">What's next? </font></div><div>I have applied/looking for funding to refactor the implementation of the existing <a href="https://github.com/tdf/odftoolkit/tree/1.0.0_SNAPSHOT/odfdom/src/main/java/org/odftoolkit/odfdom/changes" target="_blank">changes</a>. </div><div>In the nutshell, to describe declaratively this bidirectional transformation (ODT <=> changes) and generate source code (and the OASIS changes specification) from it.</div><div>Basically, the ODT grammar will be mapped to an API (a way to change the XML, like explaining what happens during an insertRow).</div><div>Naturally, aside from the underlying DOM alterations, the higher-level API would be generated as well, but this work is not done at once, but step by step exchanging existing manual written code.</div><div>By this, we could work on one logic creating also C++ code for LibreOffice or a TypeScript implementation for the browser or testing it in RUST.</div><div><br></div><div>For more information, I have tried to explain all the above (and the larger picture) within two talks at the XML Prague this year:</div><div><ol><li style="margin-left:15px"><a href="https://www.xmlprague.cz/day2-2020/#xmlpp" target="_blank">https://www.xmlprague.cz/day2-2020/#xmlpp</a> (slides)<br><a href="https://www.youtube.com/watch?v=pLwH4q-R55M" target="_blank">https://www.youtube.com/watch?v=pLwH4q-R55M</a> (video)</li><li style="margin-left:15px"><a href="https://www.xmlprague.cz/day3-2020/#nmdf" target="_blank">https://www.xmlprague.cz/day3-2020/#nmdf</a> (slides) <br><a href="https://www.youtube.com/watch?v=dkTflH3yQZE" target="_blank">https://www.youtube.com/watch?v=dkTflH3yQZE</a> (video) </li></ol></div><div>and earlier written the final vision down on 3-4 pages for a poster session and short presentation at the ACM symposium end of last year here in Berlin.</div><div>It is a summary of all the pain points I met in the past 20 years working on document formats and standardization: "<a href="https://github.com/tdf/odftoolkit/blob/master/docs/docs/presentations/2019%20-%20ACM%20DocEng%20-%20The_Next_Millennium_Document_Format.pdf" target="_blank">The Next Millennium Document Format</a>"</div><div><br></div><div>Looking forward to questions and feedback,</div><div>Svante</div><div><br></div><div><br></div><div>PS: I plan to add in the future the pictures from the slides directly to our project online documentation. </div><div>Currently aiming for the end of May to focus my work on the ODF Toolkit releases (and documentation).</div></div> </div></div></div>