>For people on poi-dev who don't know what this is all about (BTW >congrats for your nomination as a POI committer, Ken), let's summarize >by saying that I was very surprised by seeing more than 100 classes >added in Cocoon's CVS for the HSSF serializer. The Cocoon team voted 1 >in January for accepting Cocoon-specific code for POI integration, but >integration of third-party tools in Cocoon is most often a matter of a >few classes, and not 100 classes modelling a spreadsheet. >
Please speak precisely even while expressing your opinions (its the style normally used in the POI community, you'll be corrected very promptly and POI people may ignore your points as based on invalid facts...just a hint). The classes do not model a spreadsheet they are an implementation of the Gnuemric tag language. The serializer needed a tag language to work, we picked that one because it was open, in widespread use and the Microsoft tag languages suck so bad (if you need them, use a stylesheet). The tag language has nothing to do with OLE 2 Compound Document formats and everything to do with XML. All classes modeling a spreadsheet are incorporated in the HSSF usermodel package. >For full in-depth info on this, see >http://www.mail-archive.com/[email protected]/msg12408.html > Thats not a particuarly even handed analysis of the entire discussion. Please look at the entire thread and make up your mind yourself: http://marc.theaimsgroup.com/?t=101543492300002&r=1&w=2 >I strongly suggest the POI project to reconsider this decision. XML I'm -1 on this. >support would attract a lot of users, much more than a Java API. And >Cocoon isn't the only XML framework out there. > - so would porting all of COM (just because some folks might be interested in it doesn't mean it should be in the scope of the project). XML is not based on the OLE 2 Compound Document format and is NOT in the project scope. Doing this goes directly again against the project proposal for POI as proposed to the Jakarta PMC. (makes us liars) It should be noted that all of the people interested in XML interfaces to POI up to now have asked about using Cocoon in the same breath. >So much classes modelling a spreadsheet can hardly be thought to be in >the scope of Cocoon. > If you look more in depth at these classes they model a tag language and most are very very lightweight. If this had been done as a large monolithic class it would not have excited your interest I think, but technically would have been disadvantagous. <snip/> > >I guess you're talking about the generic framework, not the >HSSF-specific implementation. As said previously, this could go to >[jakarta|xml]-commons. > Do you feel there is sufficient community at this moment to support this alone? >The element processor framework is in the commons project scope >(although xml is more restrictive than jakarta). Not the full HSSF >serializer. Since every committer is also a committer on commons, >maintaining it shouldn't be a problem. > Are you volunteering to spearhead this community? >>3. Nicola Ken makes a project on Sourceforge and puts it there. I'm kinda >>getting used to this ;-P >> >That would be IMO the worst solution :( > +1/+0 (explained below) It is better than significantly expanding the scope of the POI project and creating a commons subproject with no community. I agree it is less ideal than incorporation into cocoon until there are enough similar things to support their own community. >Cocoon already has many third-party jars, and cannot hold all >implementations of ContentHandler in the world. Even more if these >implementations are related to another Apache project. > POI is not an implemnetation of the Content Handler. The HSSFSerializer is. This is more in the XML/Cocoon arena then the OLE 2 Compound Document arena >5. POI hosts the HSSF element processor in its contrib directory, and >Cocoon hosts the serializer glue class and samples, just as for other >tools integration. In order to keep poi.jar small and clean, the >serializer can be packaged in a separate poi-xml.jar, and Cocoon adds >this new jar to poi.jar in its optional lib directory. > >Thoughts ? -1 = I am against expanding the scope of the POI project into XML. Ample information and opportunity was given to the cocoon-dev list, cross referenced pacakages with proposed cocoon packages. It is unfortunate you did not reply then. I'm very against incorporating XML packages into POI. For one it makes me a big liar, for two it is an expansion of the scope of POI. For two it requires us to keep up with XML standards just to have our build work (keeping up with XML parsers and jars is hell) where Cocoon does this already. It is unlikely that folks will use the POI-based Cocoon Serializer outside of POI (even if it is possible). Does that answer your question? -Andy > >Sylvain > >-- >Sylvain Wallez > Anyware Technologies Apache Cocoon > http://www.anyware-tech.com mailto:[EMAIL PROTECTED] > > >
