Planet OpenOffice.org

The new version of ODFDOM - the OpenDocument Java library - has been released!

Most people might know about ODFDOM, for the others: ODFDOM is an Apache 2 licensed Java library to easily create, access and manipulate the ODF documents.

In biggest feature aside of a more than a dozen patches for ODFDOM 0.8 is the complete revised new ODF table API.
The table is the first feature introducing our new layered design to ease ODF usage. Some quick overview:

• Provides access to all resources stored within the ODF package, such as XML streams, images or embedded objects. This layer covers all features from the third part of the ODF 1.2 specification defining the ODF Package features. The ODF 1.2 package features are build on top technologies as ZIP package handling, W3C encryption, W3C signature and W3C metadata.

• Provides all the features of an office format, such as tables, images, numbering etc. All features are defined in the first part of the ODF 1.2 specification describing the ODF XML schema. This layer consists of two APIs representing two different views on the features:
  • The DOM API:
    Gives access to the XML, the elemental parts of the ODF schema features. With this API it is easy to manipulate all specified XML nodes extending the platform and language independent DOM API DOM API standardized by the W3C - best-known by its implementation through the browsers. It extends the DOM API using a typed DOM. For every ODF XML element and ODF XML attribute defined by the ODF grammar (the RelaxNG schema) a unique class exists, providing methods for their allowed children. The purpose is to provide the user a corset to easily write valid ODF without consulting the spec constantly. This API is very consistent as instead of laboriously writing all these classes, the sources were generated directly from the ODF schema. This generation guarantees complete coverage of the ODF specification on one side and an easy and accurate upgrade to future ODF specifications on the other.
  • The Convenient API:
    Provides a different much more high level view on the ODF schema features. This API is concerned about usability, hiding all ODF XML implementation details from the user, covering frequent user scenarios. For example, changing the content of a certain spreadsheet cell (e.g. Add 'Hello World' to a spreadsheet cell positioned at 'B2'). While in the ODF DOM API in general each class represents an ODF XML node, here a class covers multiple underlying ODF XML elements (& their attributes). Think of puzzle piece consisting of multiple smaller pieces. Therefore the typed DOM tree is being mapped to feature tree.

The design is stable now, but as often the devil is in the details. One of our greatest challenges is to find an agreement on an API. There are already some ODF libraries following different API approaches. Our idea is to find agreement with the others providing ODF users a unified ODF API, which is much more worth than the sum of all libraries. (Note: When I say unified API then I mean identical aside of the still desirable language specific differences (e.g. Java vs. Python), which follow a generic pattern and could be still bridged by automation).

To archive a common API we had the idea to break down the complexity by splitting the API finding process in two steps:

1. Instead of instantly coming up with an API suggestion for a single feature (of the Package or Convenient API ) the API should be derived from its test description. This sounds strange at the beginning, but the idea behind it is that a test scenario describes all required manipulation of an ODF feature's XML, e.g. for a table the removal of an row. In the ODF specification only the model is specified, not any ODF  behavior like the possibility of adding this row to the table.
   
2. The second step would be to map this pseudo method of the test description of a feature to a method signature following a consistent library naming convention.

Seems even API design is a test driven development.

The creation of ODF test documents and test description might be addressed by the OASIS Open Document Format Interoperability and Conformance (OIC) TC and was already described on the TC list in more detail [1, 2, 3].

If there are any further question on ODFDOM, I would happy to answer them on one of our ODFDOM mailing lists.

Svante