Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C87A337.3090407@anyware-tech.com>
Date: Thu, 07 Mar 2002 18:28:23 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.8) Gecko/20020204
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: POI Serialization code committed
References: <-1781134743.1015512881265.JavaMail.SYSTEM@webmail>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

acoliver wrote:

>>That's really cool stuff, however I have some wonders about the source
>>code that's been added to the Cocoon CVS :
>>
>
>This comes to me as a surprise; AFAIK it was unanimously voted upon like 2
>months ago.
>
What was voted in january was (taken back from the archives) "Would you 
like the cocoon-specific POI code to be hosted in the Cocoon CVS and 
shipped with the next distribution (along with the POI library in the 
/lib directory)?".

My answer to this question is +1. The goals of POI are great and having 
POI integrated with Cocoon is a must have. The problem comes from what 
we respectively understand by "cocoon-specific POI code". For all other 
components that Cocoon integrates with, this means a few glue classes. 
For POI, there are about 100 classes modelling the contents of a 
spreadsheet ! What the hell does this have to do with Cocoon ?

>The package names were cross referenced with the location in the previous
>CVS.  The only thing that has changed was the Avalonization of the
>serializers which Stefano and others proposed.
>
I checked the Avalonization : one implementation of Component and 4 
classes using getLogger().

>>- shouldn't all the ElementProcessor stuff be better located in the
>>POI > CVS repository ?
>>
>
>I don't think so.  XML processing is outside the scope of POI, and besides,
>the elementprocessor is a generic Avalon Component framework for element
>processing that can be used by other Serializers.
>
I was talking about what's in elementprocessor.impl.poi.* : I agree 
about the ElementProcessor framework. This is a generic thing that could 
well go into xml-commons or jakarta-commons for a wider use.

>>- is Cocoon the only product in which serializing XML to XLS is usefull ?
>>
>Cocoon is the only one I'm aware of, but I can't rule this out, of course.
>
Are you really serious ???? I can't agree with that : many people use 
XML without Cocoon (even if we may consider it a bad choice ;). And how 
many projects are there in Apache that deal with XML and could benefit 
of a POI serializer ?

>
>These classes were specifically written for Cocoon, they would need rework
>since they are hosted as a Component.
>
I checked the "Avalonization" : one implementation of Component, and 4 
classes using getLogger(). C'mon, let's get serious ! For serialization, 
the only interface that's really needed by Cocoon is 
org.xml.sax.ContentHandler. Is it Cocoon or Avalon specific ?

>
>They have nothing to do with any of the existing POI APIs, they merely use them.
>
... and Cocoon doesn't have anything to do with a spreadsheet class 
model, as it deals with XML and XML-aware components. Honestly, these 
classes are more POI's concern than Cocoon's one.

>>>From what I can see, all classes in 
>>components.elementprocessor.impl.poi.* are really POI-specific and can
>>be understood and maintained only by people with POI knowledge. So why
>>aren't they managed by the POI project itself and delivered in poi.jar ?
>>
>
>Well, they have nothing to do with the POI project at large. They were
>written just so Cocoon could serialize an XML tag language (we picked one
>for Cocoon) to XLS.  We picked one that we thought was the nicest and most
>widely availabe.
>
>I don't think you really need any POI knowledge if you'd like to help.
>The POI::HSSF API is really simple and furthermore those classes are
>documented not only through javadoc but the Gnumeric
>(http://www.gnome.org/projects/gnumeric/) XML Schema that POI committer Marc
>Johnson donated, as well as the DTD.
>
Well, you're saying here that XML is a concern of the POI team ;)

Don't you think XML import/export could be a real added value to the POI 
project ? Hiding this feature in Cocoon goes against an increased use of 
POI.

>>The strength of Cocoon is its ability to integrate many components
>>(XIndice, JFor, FOP, Velocity, to mention a few). But IMO, it should
>>only host "glue" classes for these components and not the components
>>themselves.
>>
>
>Ahh I think you're thinking the POI project has something to do with XML or
>templates, but it does not. It's a Java API and implementation project to
>read-write legacy formats, not to do *conversions*.
>
I'm not talking about templates at all. But yes, I think it would be 
good for POI to allow conversion between XML and legacy format.

>>>From a project management point of view, we have the danger for part of
>>the traffic on cocoon lists being related to POI, which means noise for
>>Cocoon and loss of information for POI, and lots of POI-related entries
>>in Bugzilla (user reports and patches from the POI team).
>>
>
>Currently, traffic on the Cocoon lists related to XML Serialization of XLS.
>IMHO the problem you envision is identical to the ones Cocoon has with other
>projects it uses.
>
I disagree. When posts are related to projects integrated with Cocoon, 
either the answer is simple and given as a reply, either people are 
directed to the respective mailing lists of these projects. With the 
serialization stuff, I envision many questions like "Andy, are you 
listening ?" (and will you be listening, since POI doesn't care about 
XML ?) or "Ask to poi-dev, they will send us a patch".

>>So, what do you think about moving (back ?) the ElementProcessor stuff
>>to the POI CVS, and keep only the Serializers in Cocoon CVS ?
>>
>
>I consider these to be part of the serializer to be honest.  It has nothing
>to do with anything else in POI.  I really don't want to host interface
>classes to all the projects we provide POI functionality that have nothing
>to do with POI.  That would be kind of messy.  I mean, I'll soon be
>developing MIME mappings and interfaces between POI and Lucene and I really
>don't want those to live in POI either (even though some will be specific to
>using POI from Lucene).
>
Damn ! So the aim of POI is to flood in ("pollute" came to my mind) all 
projects that want to integrate it, even if this integration relies on 
well-established standards like SAX and MIME ? Sorry, I can't be happy 
with this. There are other ways to promote POI. Having builtin XML 
support is IMHO one of these.

>
> The scope of POI seeks to be really small and focused: Java ports of OLE 2
>Compound Document based file formats.  We have no XML classes nor do I
>really want any there.
>
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.

Don't you have great ambitions for your baby ? Announcing 
XML<->Word/Excel roundtrip support in POI is likely to attract _a lot_ 
of people. A lot more than just a Java API.

>
>If you deem this unfit for Cocoon is there an XML project somewhere for
>Cocoon Serializer tag implementations?
>It seems that there is a need of making a project that converts file formats
>in xml.
>
As said above, there may be room for the ElementProcessor framework in 
[xml|jakarta]-commons. Cocoon could use it, but other projects as well.

>
>What do you think?
>
You've read it inline ;)

>
>-Andy
>
Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org