On Wed, 1 Jun 2011, robert_w...@us.ibm.com wrote:
But I see this as pulling in two directions:
1) On the one hand it is a good fit for a module in an OpenOffice SDK, so
the OpenOffice project might be a good fit. On the other hand ODF is an
application-independent document format, not necessarily just for
OpenOffice. So we might not want to bury it as a component in this much
larger project.
It's not impossible for a project to live in one TLP, but be referenced by
another. One example is the various projects within the Hadoop family.
Most of them are independent TLPs, which do collaborate and work together,
with the websites linking each other.
2) It is complementary to POI, doing some of the same functions with ODF
that POI does with MS Office binary and OOXML documents. But it is a
little bit of scope creep if POI takes on non-Microsoft formats. I could
live with that, if done consistently in how POI describes itself.
I can't speak for the whole project, but personally I'd be interested in
discussing how the POI mission statement could be expanded, and if that'd
work well for everyone.
Another option of course is to incubate it toward its own TLP
eventually. We do have Java and C# libraries already, along with some
useful ODF-processing XSLT scripts, a servlet "runner" and an ODF
validator components.
It may be worth bringing all of these in as one podling, seperate from the
main OOo one. Once in the incubator, the communities can decide where they
want to go, which could be aiming for a TLP for all the ODF tools, or
could be some moving to POI and some into the OOo podling.
I'll have more cycles to discuss that on the POI dev list once we get
the OpenOffice podling off to a smooth start.
Hopefully discussions on the POI dev list can shake out a few mentors (I'm
happy to mentor an ODF Toolkit podling, but it'd take more than just me!),
then we could put together a proposal to bring in the ODF Toolkit. As Bill
has pointed out, it could be a 2nd proposal alongside the OOo one, and
potentially a quicker one to get in as the situation is simpler.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
