incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <>
Subject "ODF Track on LibreOffice Conference" or "An operation focused ODF Toolkit approach"
Date Wed, 11 Sep 2013 19:03:13 GMT
There will be an ODF Track on the LibreOffice Conference in Milan
(Italy) in two weeks.

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

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 -

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

The office relevant parts are currently under GPL2 available via git
clone from
There an extension from our odfdom folder, which can be found under
office/ 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
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

If you like to meet me in Italy on the conference and have some
discussion on ODF, just let me know.


View raw message