incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Request: Can "proposed committers" introduce themselves?
Date Wed, 08 Jun 2011 13:58:51 GMT
"Andre Schnabel" <> wrote on 06/08/2011 04:40:56 AM:

> > Von: Yegor Kozlov <>
> > 
> > I'm interested in bringing the ODF Toolkit to Apache and integrating
> > this API with Apache POI. With ODF, POI will become a universal API
> > for Office documents covering most of popular office formats.
> As I see this the second time in an introduction now - please be aware
> that the current project proposal is not about ODF toolkit.
> Although ODF toolkit once was a sub-project of OOo, it is now a
> seperate project ( and (afaik) does not 
> share code with People from IBM might give more
> details, as they helped to create ODF-toolkit as independend project.

This was in a previous discussion. I am interested in bringing the ODF 
Toolkit over to Apache. It is already 100% Apache 2.0 license.

I'm a Steering Committee member on the ODF Toolkit Union, but obviously 
there are others, and we'll want to bring them and the developers in on 
this discussion.

What is not resolved at this point is whether we target the ODF Toolkit as 
part of the OpenOffice, target it as a new TLP, or target it to POI.  I 
think one could make a good argument for either one of these.  My main 
recommendation was to defer this discussion and decision until after the 
debate on the OpenOffice proposal was done.  Then we can engage the ODF 
Toolkit Union in this discussion.

The connection of OOo and ODF Toolkit is like this, from app developer 

1) If you want to do desktop client manipulation of documents, with a GUI 
and within the editors, then we have UNO-based scripting.  This could 
include some kinds of batch processing.

2) If you want to do server side processing of documents, then you could 
run OOo on server as well, with the obvious performance constraints.  Or 
you could use the ODF Toolkit, which is a lighter weight solution.  POI 
developers would be familiar with this advantage, as well as the 
liabilities, e.g., who calculates/updates formulas, who creates/updates 
metafiles, etc.

A sufficiently complex business application based on OpenOffice is going 
to involve document manipulations at both tiers.  For example, we recently 
(at IBM) made an insurance solution that involved using Symphony, extended 
with a Plugin, submitting documents into a workflow, where they were 
introspected and validated using the ODF Toolkit.

I'm sure many of us are familiar with the range of documents out there, 
from fully structured XML, forms, to semi-structured documents, to 
unstructured free-form documents.  From what I've seen the sweet spot for 
ODF/OpenOffice automation is in the semi-structured area, where it is not 
quite structured enough to go with a form, but requires some free-form 
work by the user in a familiar word processor.

So wherever the code goes, I think we'll want/need close technical 
coordination via a triangle of concerns:

1) The ODF editors, OpenOffice, LibreOffice, etc.
2) The ODF Toolkit
3) The ODF Standard, i.e., the Technical Committee at OASIS

I intend to be involved across all three.  I think that makes sense for 
anyone interested in the document automation scenarios, things that go 
beyond mere interactive editing.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message