Skip to content

start:

ODF Toolkit: Proposal

Rationale

The proposal is based on the following requirements and experiences:

  • Many customers use already OpenOffice.org as basis for their work. OpenOffice.org therefore has proven its usefulness for ODF document processing and creation in real life. However, customers are also looking for alternatives that provide the document related functionality of OpenOffice.org in a lightweight fashion.

  • Each individual project that is about ODF document creation and processing requires a different functionality. This means that there is not a small subset of functionality that an ODF Toolkit must provide to be sufficient for the majority of customers.

  • Many projects require layout/viewing/printing capabilities in addition to an ODF Toolkit.

  • Many document creation and processing related projects are implemented in Java.

  • A new package structure for OpenOffice.org is already on the wish-list of the OpenOffice.org project.

Proposal Summary

  1. The ability to use OpenOffice.org as a programming framework for creating and processing ODF documents rather than to use it as a desktop application will be improved. This will be achieved by transforming an appropriate subset from the OpenOffice.org source code basis, and by adapting it to the new purpose.

  2. A home for components that can be used for processing ODF documents and that are either based on the new ODF Toolkit, or complement it, will be created.

Both together will constitute the ODF Toolkit, which is a toolkit for ODF document creation and processing. This toolkit will share its source code with the OpenOffice.org desktop application where ever this is reasonable. That is, based on the OpenOffice.org source code, there will be the OpenOffice.org suite, and an ODF Toolkit, which is tailored to processing ODF documents outside traditional office desktop applications.

The ODF Toolkit will be developed by a new OpenOffice.org project.

Some More Details

The transformation of the OpenOffice.org source code mentioned above will include the following items, but is not limited to these:

  1. Repackaging and modularization: OpenOffice.org gets splitted into at least three packages:

    1. The URE: The already existing UNO Runtime Environment (URE) will be used as a basis for OpenOffice.org.

    2. The toolkit: The toolkit consist of the modules that are required to create and process ODF documents, and their interfaces. It will use the URE as a basis.

      The toolkit's public interfaces will be UNO interfaces.

    3. The OpenOffice.org desktop application: This is the OpenOffice.org application as we know it today, but based on the toolkit.

    Each of these packages is considered to be a product of its own, that is, URE and toolkit can be downloaded and (in any case) installed separately.

    The packages may be further modularized.

  2. UNO-Java-Binding: The usability of the Java UNO-Binding for Java developers will by analyzed, and, where applicable, improved.

  3. OpenOffice.org use as framework: The usability of OpenOffice.org as a programming toolkit will be analyzed (i.e. bootstrapping, office process), and, where applicable, improved.

  4. ODF APIs: Definition and implementation of new APIs, that

    • are more ODF-like than the existing ones,

    • make use of new UNO features, like services,

    • consider the experience we made with the existing APIs.

  1. Additional layers: Definition and implementation of additional API layers (for instance an ODF package layer, that provides access to ODF packages only).

The ODF Toolkit Project will provide a home for components that can be used for processing ODF documents outside the traditional OpenOffice.org desktop application, and that are either based on the new ODF framework, or complement it. Examples are:

  1. Transformations into other formats, in particular XHTML.

  2. “Adapters” that add ODF support to other tools and products, for instance content management systems.

  3. Validations tools.

  4. API Snippets for re-occurring ODF related tasks.

Benefits

  • The demand for an ODF Toolkit gets addressed immediately.

  • The scope of OpenOffice.org will be extended, making it more attractive to contributors.

  • Customers and the OpenOffice.org project itself get an ODF Toolkit that can be used whenever an UI-less document processing is requested.

  • A product exists that can be given to customers to get feedback which of their requirements are not met.

  • Customers understand that the API is a first class citizen of OpenOffice.org, and in particular, that they can submit bug reports and feature requests for the API.

  • A home will be established for the implementation of APIs that are not required by the OpenOffice.org desktop application and OpenOffice.org macros.

  • A home will be established for new components that are not used by the OpenOffice.org desktop application, but are useful for ODF document creation and processing.

Next: Transition Steps

Previous: Background Information

Back to main page.