There will be an ODF Track on the LibreOffice Conference in Milan (Italy) in two weeks. http://conference.libreoffice.org/2013/en
The program is not out, yet. But I am being told that the ODF track is very likely to be on Wednesday the 25th of September. I will have a session on ODF XML change-tracking and on how file formats are not the wisest way to solve collaboration. The session is called: " Real-time compatible ODF change-tracking Abstract: The OASIS Advanced Document Collaboration subcommittee is working on an update of OpenDocument change-tracking (CT). The update will not only enhance the existing CT feature set to the current state of the art, e.g. tracking style changes, but lay the foundation for the standardization of real-time collaboration (RTC) by making CT compatible to RTC. The theory part - new design in a nutshell Pattern of trackable changes of OpenDocument will be derived from common user actions and defined as "operations". The overall design of ODF change-tracking will change from a before/after XML design to a sequence of serialized operations, improving the merge ability using Operational Transformation. To split overall complexity the overall set of valid documents defined by the RelaxNG schema will be split into smaller XML components based on semantic entities known by the user, e.g. table, image, paragraph and character. A complete XML document tree is mappable to a component tree and operations are always referring to a component they are altering, choosing one of the 6 meta operation types: add, remove, split, merge, move and replace." Why this might be important for our ODF Toolkit? I have started to extend our ODF Toolkit on the functionality of operations. Such operations are being created from a file, or mapped back into a file. Operations are just another way to represent a document. In the library they are represented via JSON to be wired over the Internet to a client, such as a browser or mobile device. Each user action on the client will create a new operation and will be wired back to the server when the changed document is closed or downloaded as ODF. Most important, via operations it is very easy to change/edit a document and changes of multiple users are very easy to merge. AFAIK most of our Simple API is only appending changes to the document and not adjusting for instance list properties easy and/or applying arbitrary styles. An example of usage can be found online, although the demo (at the end) is at the moment out-of-order - https://www.ox.io/ox_text The merge of my work for the backend of above project back to the ODF Toolkit is under discussion, but for those curious, the sources are already available under http://git.open-xchange.com/ The office relevant parts are currently under GPL2 available via git clone from http://git.open-xchange.com/git/office There an extension from our odfdom folder, which can be found under office/com.openexchange.office.odf/odfdom the "develop" branch is the one of most interest. Note: I do not use the Simple API, my work is solely based on the ODFDOM repository. I would claim today that the work is mostly feature complete for text documents, but needs some polishing like some restructuring of the new classes. Still I wanted to let you know already. It should be mentioned that similar approach has been used not only for ODF, but as well for OOXML to map OOXML Text documents to operations. My idea was that operations might become a kind of lingua franca among documents (the third file format is the HTML within the browser office). The OOXML functionality can be found in the same office repository among office/com.openexchange.office.ooxml If you like to meet me in Italy on the conference and have some discussion on ODF, just let me know. Regards, Svante
