Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Thu, 7 Mar 2002 23:05:48 +0100 (CET)
From: giacomo <giacomo@apache.org>
To: <cocoon-dev@xml.apache.org>
Subject: Re: POI Serialization code committed
In-Reply-To: <3C87A337.3090407@anyware-tech.com>
Message-ID: <Pine.LNX.4.33.0203072259400.5078-100000@lapgp.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


As always when Sylvain gets engadged he has very good arguments which
convinced me to support moving thoes classes out of Cocoon and only
leave the serializer and Avalon component glue code in Cocoon's CVS.

We have to see where the other code will best fit into other project (if
the POI team cannot be convinced to hold it in their CVS).

Giacomo

On Thu, 7 Mar 2002, Sylvain Wallez wrote:

> 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
>
>


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