Skip to content

start:

ODF Toolkit: Design Aspects

Below a couple of design aspects for an ODF Toolkit that have been analyzed during the work on the ODF Toolkit proposal.

The Relation to OpenOffice.org

When implementing an ODF Toolkit, there are two options how to start:

  1. from scratch;

  2. by (re-)using the OpenOffice.org code basis.

The tasks one could do with ODF documents are complex, and therefore require complex implementations. Even tasks that appear easy to implement may require complex implementations. For instance, setting the value of a text field or table cell may require to calculate a localized values of the field or table box for presentation, or may require a re-calculation of other text field or table cell values. Many task furthermore require a layout. This obviously applies to printing tasks or conversions to other document formats, like PDF. But it also applies to simpler tasks, like updating the numbers of illustrations contained in a text document after a new illustration has been added.

In OpenOffice.org, all these tasks are implemented already. It therefore seems to be very reasonable to use the OpenOffice.org source code as basis for the new toolkit, and to not start from scratch. The benefits are:

  • The OpenOffice.org project remains one project, and the OpenOffice.org community remains one community. A split of the OpenOffice.org community into a desktop application and a toolkit community is avoided.

  • Synergies between the toolkit and the desktop applications can be used. In particular, if both use the same source code, both benefit from improvements of the source code.

  • The scope of the OpenOffice.org project is extended from a traditional desktop application to a toolkit for ODF based document processing.

  • The initial development time for the toolkit is decreased.

In some cases, we may however assume that parts of an ODF Toolkit nevertheless get implemented from scratch. This is the case if the new components either extend OpenOffice.org's functionality, or if they replace existing implementations.

An example for this may be the composition of a document from text blocks according to specific rules. This is a reoccurring task, which (most likely) will never become part of a traditional office application. However, if we understand OpenOffice.org not only as a traditional office application, but as a toolkit for ODF document processing that also, but not only, provides a user interface, then even these components can be seen as part of OpenOffice.org again.

Language Binding

The most essential part of an ODF Toolkit is its API. This API could be a programming language specific API (for instance a Java or C++ API). Or it could be a programming language independent API that supports bindings for multiple programming languages, like Java, C/C++, Phyton, etc.

If the API is programming language specific, then the most reasonable choice seems to be Java, because it provides platform independence (but no programming language independence), and has a good support of XML.

If the API is specified programming language independent, the only reasonable choice for an OpenOffice.org project is obviously UNO.

There are arguments for both options. Arguments for an UNO based API are:

  • Components based on such an API could be used by a wider range of applications than only Java applications.

  • Components based on such an API could be used by OpenOffice.org (and other office applications) that are implemented in C++.

  • The concept of a program language independent API seems to fits very well into an ODF universe based on open standards and open source.

Arguments for a Java API are:

  • Java has a broad acceptance in the XML world, that UNO and other component technologies do not have so far.

  • Java interfaces would allow to use the full range of Java data types and classes, and therefore fit better into an XML-Java-world.

  • Many business solutions are implemented using J2EE.

While the arguments for a Java API are all valid, the arguments for an UNO based API actually seem to be stronger, especially if we take into account that UNO provides a Java language binding. Therefore, a UNO based toolkit would not lock-out Java programmers. However, due to the importance of Java, it seems to be reasonable to analyze whether UNO's Java binding may be further improved.

Abstraction Level

The APIs of an ODF Toolkit may have different abstraction levels from the ODF XML saved in documents. On the lowest level, there is the DOM or SAX event stream of an ODF document. On the highest level, there are APIs that include sophisticated and easy usable interfaces, but have not much in common with the underlying XML itself. The OpenOffice.org API is an example for an high-level API. It allows the creation and modification of ODF documents, and therefore is a possible option for the ODF Toolkit's API. But unfortunately, the OpenOffice.org API has been developed independent of ODF, and therefore uses different terminologies and makes unnecessary abstractions. Its scope furthermore is much broader than only the creation and modification of ODF documents.

But, if the document related interfaces are separated from the remaining functionality of the OpenOffice.org API, and if they are adapted to ODF where appropriate, then the resulting API will be an appropriate API for the toolkit, marking the upper end of the abstraction level scale (see below figure).

An example for a low-level ODF API is an ODF Package API that provides access to ODF packages and optionally transparent access to flat XML files. Another example for a low-level API is an ODF DOM API, that is, a DOM-like API that takes the ODF schema into account.

High-level APIs can be implemented on top of the low-level APIs (in the sense that each call to a method of the high level API triggers a sequence of calls to the low-level API), but also separately (see below figure).

Whether low-level APIs can and should be implemented within OpenOffice.org depends on the purpose of the APIs. Wherever this appropriate, implementations that initially are implemented outside OpenOffice.org should replace existing implementations in OpenOffice.org.

Implementability

When implementing a toolkit, one first has to define the APIs that the toolkit shall provide, and then can start with the implementation. In practice, especially if a toolkit is developed from scratch, that may lead to the situation where the APIs of a toolkit are defined already, but are not fully implemented, or where an API turns out to be not implementable. Both is not acceptable for customers of a toolkit, that need to know that the APIs they are using are stable and implemented.

For low-level APIs, the implementability of an API can be improved by deriving it from the ODF schema directly using formal rules, because this allows implementors to generate their implementations or portions of it from the schema, too. For high-level APIs, this option does not exist. For these APIs it is therefore advantageous if they can be derived from existing APIs that have been implemented already.

IDE Support

The acceptance of a toolkit can be increased by having an IDE support for the toolkit. An UNO based toolkit here benefits from the OpenOffice NetBeans Plugin for UNO components/applications or the Eclipse Plugin that are currently under development.

Modularization (Divide and Conquer)

As stated above, the implementability of a toolkit API is essential. A complex general purpose API that can be used for many different purposes but in real life is implemented only partially actually is not of any use. If we take the OpenOffice.org API as well as modifications or enhancements of this API aside, then in the short term the definition of a general purpose toolkit API therefore is only an option if the API and its implementation can be derived directly from the schema. The resulting API naturally could be only a low-level API, for instance an ODF DOM API.

For purposes where an API like this is not sufficient, it is reasonable to define multiple specialized but less complex APIs that each of its own is implementable with reasonable effort, and where each of these APIs is for a certain purpose. Possible specialized APIs are:

  • An ODF Package API that provides access to ODF packages and optionally transparent access to flat XML files.

  • An Import or Creation API that is tailored to the import of documents from other file formats or to the creation of documents from scratch.

  • An Export APIs that is tailored to save documents or to convert them into other file formats.

  • A Data Entry API that allows it to fill certain ODF elements (like text fields) with data.

Please note that these APIs are examples only. In fact, it needs to be researched which APIs promise to be of the largest value for ODF and OpenOffice.org. A Data Entry API for instance may not be required, because OpenOffice.org has also a high-level API that can be used for this purpose.

Previous: Case Studies

Back to main page.