incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert_w...@us.ibm.com
Subject Re: Request: Can "proposed committers" introduce themselves?
Date Wed, 08 Jun 2011 16:04:46 GMT
dsh <daniel.haischt@googlemail.com> wrote on 06/08/2011 10:37:46 AM:

> 
> On Wed, Jun 8, 2011 at 3:58 PM,  <robert_weir@us.ibm.com> wrote:
> > 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.
> >
> 
> Of course the ODF Toolkit isn't a golden fleece for server side ODF
> processing. I would rather call it a good compromise offering some
> room for improvement. If we would have had a choice we would have
> preferred a headless OO runing on either AIX or z/OS ;) For instances
> you still have to code a comprehensive amount of XSL stylesheets if
> using the ODF toolkit. One drawback we faced was that customers
> created their ODF documents during design time using Symphony and
> during runtime while mass-producing business correspondence documents
> the ODF Toolkit generated documents which were not 100% formatted
> equal to what has been created in Symphony earlier on. Thus our
> preference to use the same formatting engine (i.e. Symphony/OO) during
> both design time and run time.
> 

The ODF Toolkit Union has several projects. It sounds like you have been 
using the XSLT Runner component?

We also have ODFDOM.  This is a Java API that uses a code generation 
approach, giving a typed DOM that is 1:1 with the ODF schema.  So this can 
read and write documents and preserve 100% of the its contents, 
formatting, metadata, etc.

On top of that (we all need layers, right?) we have the Simple Java API 
for ODF, which is a high level API for manipulating the document.  So 
things that might be a complex operation touching many ODF elements, like 
deleting a column in a table, are done in a single function call in the 
Simple API.  We also took a set of "navigators" to select interesting 
content in the document.  So you can do a regular expression search and 
replace.  But also search for all text with style = "header 3" and then do 
something on it.  You can extract the text of a document in one line of 
code.  You can copy a presentation slide from one presentation and put it 
into a another in one line of code, etc.  The cool thing, in my opinion, 
compared to other ODF API's, is because the Simple API is based on ODFDOM 
and ODFDOM is generated from the ODF schema directly, then the Simple API 
manipulations preserve all of the existing document content. 

You can see the details here:  http://simple.odftoolkit.org/

We also have a validation component, with tools for validating conformance 
of ODF documents,

And we have a C# ODF API, which I don't know so much about.


Regards,

-Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message