acoliver wrote: >>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). > Ok. Strict and precise mode on. I usually prefer friendly discussions that lead to a consensus, but let's adapt to the POI way.
This is a sum-up of my opinions. To be more precise : too much code in Cocoon for a third-party library integration. And this code is too much related to this third-party library. >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/cocoon-dev@xml.apache.org/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 > These are my thoughts and opinions. People can travel the thread at will in the archives. Thanks anyway for the pointer to the full thread, where people can see that POI integration is very welcomed, but also that I'm not the only one to have these fears about so much code. >>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) > Big words. Nothing is written in stone, and all projects evolve over time. Accepting evolution means the project can adapt to the community feedback and go beyond the expectations or thoughts of its originators. Look at what happened to Cocoon : it started as a small servlet written by Stefano to build Apache web sites and it is now a major player in its area. This is because it accepted evolutions and revolutions. >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. > I can't believe you really think Cocoon is the only tool out there where XML<->POI integration could be useful. Or is because this serializer has always been presented as a Cocoon component ? Look back to http://www.mail-archive.com/poi-user@jakarta.apache.org/msg00079.html : XML_DBMS, Oracle XSU and XSQL. No mention of Cocoon. As I said in this thread "XML is now a dominant technology in the software arena, because it moves software development from sequential logic to data transformation. And reading/writing legacy formats *is* data transformation." You can't ignore XML, or POI will stay a small project for people having in-depth knowledge of legacy data structures. >>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. > Granted, I looked deeper at it because of the lots of files that went down through cvs update. But this doesn't change the problem. > ><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? > We're talking here about a 10-classes framework. The purpose of moving it out of both POI and Cocoon is not to create a fully-fledged Apache project, but to allow other projects to use it as well without depending neither on POI nor on Cocoon. The community will start around the HSSF serializer and grow when other projects implement new serializers. >>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? > No need for a charismatic leader (see above), which I do not pretend to be. >>>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 > XML is a very general-purpose technology, and the arena a document belongs to is defined by its semantics. As far as I can say, Gnumeric DTD is more in the spreadsheed arena than Cocoon's one, which is DTD-agnostic (handles _any_ DTD). >>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. > Ok. I was overworked when the vote was taken back in January and didn't look deeper at it. But once again, the usual integration code for a third-party tool is a few small classes. That's why I didn't investigate further, just as, I think, many Cocoon committers. >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). > Will people blame you and say you're a liar if this is good for the health and spread of the project ? I'm sure of the contrary. >Does that answer your question? > I'm starting to wonder about the future of POI if you refuse to consider XML as a general-purpose technology, just as a java compiler. > >-Andy > Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
