acoliver wrote: >>Ok. Strict and precise mode on. I usually prefer friendly discussions >>that lead to a consensus, but let's adapt to the POI way. >> > >Perhaps your not aware of it. Your tone doesn't come off that way. >
This discussion didn't start in a friendly way, so this isn't my usual tone. I hope next discussion will be more friendly ;) >>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. >> > >Please take a closer look at the classes. "so much code" is referring to >the number of classes. If you'll look closely you'll see that there is very >little code there. Its just very well encapsulated. I had the same >reaction to the implementation when I first saw it. I grew to appreciate >it's simplicity and the sheer LACK of code needed to implement things within >it. > I totally agree with you on that point. To demonstrate my sincerity, consider the new sitemap engine that's in Cocoon (known as "interpreted engine" or "treeprocessor engine"), which I wrote. In this new implementation, every "verb" of the sitemap language is implemented using two small classes, while the previous engine had a single big XSL handling all verbs. Going back to HSSF serializer, the number of files attracted my eyes, but my reaction, and hence this discussion were caused by the functional content _be it one or many classes_, and my deep feeling that XML support in POI is a good thing for it. This last point may seem presomptuous as I'm totally new to POI, but I learned the importance and power of XML over the years not only for web publishing, but mainly for structured data manipulation, be it purchase orders, satellite telemetry or industrial appliance monitoring (yes, all of that). >>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. >> > >true. I'm giving my feedback. > >>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. >> > >POI started out as Excel only. > >>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 ? >> > >Are you volunteering to spawn a project around non-cocoon uses for XML-POI? >Most of my XML work is centered around Cocoon. I'm ill-qualified to >implement these ideas for you. > Am I so unclear ? So once more : there's no need to implement anything else than the org.xml.sax.ContentHandler interface. This interface is a worldwide (and even cross-language) standard, which is now included in JDK 1.4. It allows to integrate the serializer in any tool that handles XML. There's *absolutely no need* to implement anything else. No need to spawn anything to implement I-don't-know-what-ideas. Just org.xml.sax.ContentHandler. Period. >>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. >> > >I've seen those projects. Are you volunteering to start a project on that >level? Such exceeds me. You seem to have some ideas that are more >expansive than what the creators of this software had in mind. Are you >volunteering? > I don't know the details of these projects, but they certainly all know how to deal with a ContentHandler. That's all the power of this simple standardized interface. If people have only a Cocoon serializer, they can't use it with these tools. And since some of these are competitors of Cocoon, their users won't even know the existence of a serializer. >>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. >> > >I disagree. POI has attracted a number of very talented developers in a >pretty short period of time who were able to come up to speed on the skills >required and work in their area of interest. A number of users have been >attracted as well. Please research the POI project further before making >these assertions. > I did, at least since you joined Jakarta. And the adjective "small" came in comparison with the high traffic on Cocoon and Avalon lists, which is sometimes so hard to follow. >>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. >> > >There was a message that cross referenced what was proposed quite in depth >with prior existing classes as well. > >>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. >> > >even a small project requires some semblence of a community to justify the >added complexity of seperating it from larger project do you not agree? > >For intellectual debate, what if POIFS was moved into Jakarta commons? It >would increase the difficulty of installing POI, make it harder to find and >more. Do the costs of this justify any benefits? > That's nonsense : you're talking about moving a core part of POI to commons. I'm talking of 10 classes that have *no dependency* on POI. >>>Are you volunteering to spearhead this community? >>> >>No need for a charismatic leader (see above), which I do not pretend to be. >> > >I see. I'm not sure this really makes these particularly accessible to >other projects unless someone is volunteering to evangelize their use. We >could just bury them deep underground to achieve the same effect. Unless we >have a volunteer. I personally do not have the time at the moment to do >this. > I'm sure there we can find lots of possible uses for this small and cute serialization API that could bootstrap the community. I'll think deeper about this (I need to sleep now...) >>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). >> > >I missed the point in the above paragraph. > This may be what caused all this unpleasant discussion. XML is not a goal, but a means. Just as the java compiler that allows you to represent any program, XML allows you to represent any data. Nothing more, nothing less. This means you cannot say "XML is not a POI concern". POI handles data, and this data can be expressed in XML. And it's easier for many people (not only XSLT geeks) to handle XML data. Far easier than learning a new Java API. >>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. >> > >I see. I'm pretty overworked right now. I know how it feels to be >overworked. I've only seen messages from 3 cocoon committers. > What do you mean ? POI people like to be precise, you said. >>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. >> > >*shrugs* Are you quoting Machiavelli? > Nope. Just common sense. >>>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. >> > >java compiler? Huh? > See above discussion about the general applicability of XML everywhere where there is some data. >the law of the hammer? > >*shrugs* so far the growth has been quite remarkable despite our not >becoming a "me too XML-enabled" project. Its not to say that I do not hope >XML projects use POI, I just prefer to leave XML to the experts and that POI >focus on the very complex problem area of mapping the there over complicated >legacy file formats to APIs. > Like it or not, XML *is there* and is going to last. OpenOffice stores in XML. M$ Office stores (at least tries) in XML. Gnumeric stores in XML. XML is only data, but data that anybody in the world can read and write, both with its eyes and hands and with its favorite software tools, be them Java, VB, C++, or whatever language you want. Don't you want to open POI to such a wide potential ? I don't understand your reluctance for XML support in POI. Or do you associate XML with web site publishing ? I hope I can convice you of the general applicability of XML. Now about "experts", people certainly don't have to be experts to understand SAX (which means "Simple API for XML"). I can even point you to introductory material that shows how easy it is to implement ContentHandler. >Anyone in the POI community feel like thats not a big scope? > >Somewhat offtopic: >Oh and welcome to the POI community Sylvain. I've enjoyed much of your work >on Cocoon. > Thanks ;) And sorry for this noisy beginning in this community. But this topic is seems really important to me, both for POI and Cocoon. 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]
