Thoughts on an OpenDocument Toolkit

http://blogs.sun.com/GullFOSS/entry/thoughts_on_an_opendocument_toolkit

Thoughts on an OpenDocument Toolkit

By Michael Brauer

Welcome to the readers of this new GullFOSS blog. I'm Michael Brauer, OpenOffice.org XML project lead and OASIS OpenDocument Technical Committee (TC) chair. I intend to blog here constantly, and my primary topic for this blog will be OpenDocument (what else?).

In my first series of blogs I will write about the topic of OpenDocument toolkits (in short ODF toolkits). That's a topic we (my colleagues at Sun's OpenOffice.org team and myself) are working on for a long time already, and that gets more and more attraction. It was for instance a topic at the OOoCon 2006 in Lyon last week, and my TC colleague Robert Weir, whom I met in Lyon, posted a proposal for an ODF toolkit here a couple of day ago. So, it seems that the time has come to share our thoughts and experience with the public.

First of all: What is an OpenDocument toolkit? In short, it is a framework that has a standardized API and that allows the creation and manipulation of OpenDocument files in a lightweight fashion outside office applications. This is something that is demanded in a number of projects, and where we could gain already some experience in (unfortunately non-public) customer projects, but also in the OpenOffice.org development itself, for instance when developing filter components. BTW: There are many synonymous names for an ODF toolkit, like ODF framework, or ODF development kit, but I will only use the term OpenDocument/ODF toolkit for toolkit itself, and the term ODF/OpenDocument API for its APIs.

When designing ODF APIs, and when implementing an ODF toolkit, where are a couple of aspects that have to be considered. For instance:

• The languages bindings: Shall it be a programming language specific API (for instance a Java API), or an API that provides multiple language bindings.

• The "scope" of the API: What are the classes of use cases that can be implemented using the API. Examples are APIs for creating OpenDocument documents from scratch, APIs for filling existing documents with (customer or use case specific) data, APIs for conversion of documents from and to other formats, etc. Each of these use cases has its own requirements.

• The abstraction level of the API. The range starts here with low-level APIs similar to DOM or SAX, and ends with high-level APIs which offer a high level of abstraction from the (OpenDocument) XML that is saved in files.

Beside this pure API related questions, we also have to take into account the interoperability with supplemental components, like OpenDocument viewers. One may actually consider them to be part of a toolkit, but I think its better to examine them separately, because they can be used with or without the API and framework we are discussing here. The ODF Viewer plug-in for Firefox that we have implemented for instance can be used for viewing documents created using an ODF toolkit, but of course also can view documents created by one of the ODF office applications, like OpenOffice.org or KOffice.

It goes beyond the scope of a single blog entry to discuss all of these topics. I'm therefore concentrating today on the language bindings, and will come back to some of the other topics in follow-up postings (in about two weeks, because I will be in vacation for about a week now).

The question regarding the language binding is whether the API should be an API for a specific programming language (like Java or C++), or whether it should be an programming-language independent API that supports bindings for multiple programming languages, like Java, C/C++, Phyton, etc. There may be exceptions for some low-level APIs, but I think in general it's important that an ODF-API provides bindings for all these languages. Java for instance is required because it in my point of view is the programming language for XML based application if we take declarative languages like XSLT aside. C/C++ is required because that's the programming language most (ODF aware) office applications are implemented in. So, if we want that the lightweight toolkit and office applications can share components, we need these multiple bindings.

Actually, the language binding issue is not new and not related to an ODF API, but applies to all APIs. The OpenOffice.org project, being a platform independent project, has to deal with this situation for may years now, and has developed a technology called UNO to open its APIs to many programming languages and platforms. The following description is taken from OpenOfffice.org web page directly:

UNO (Universal Network Objects) is the interface-based component model of OpenOffice.org. It offers interoperability between different programming languages, different object models, different machine architectures and different processes; either in a local network or even via the Internet. UNO components can be implemented in and accessed from any programming language for which a UNO language binding exists.

Currently, that's Java, C++ and Phyton. Some more bindings are available that support the access to components, but cannot be used for component development.

UNO is used by OpenOffice.org to achieve platform and language independence, but it also available stand-alone as so called UNO Runtime Environment (URE). So, it would be available for use in an OpenDocument toolkit without adding any of the OpenOffice.org code itself to the toolkit. UNO further has proven its value in real life already. For this reason, it seems to be a solid basis whenever an API of the OpenDocument toolkit shall be platform and programming language independent.

That's it for today. If you like, stay tuned for my follow-up postings in about two weeks.