Peter Donald wrote: > > <snip> > > So, my proposol is to add a getMimeType() method to the Source interface > > and an "XMLizer" component to the xml package. This XMLizer gets > > a mime-type and an input stream as input and creates sax events > from this. > > This will > > - decouple the source and the xml package totally > > - the XMLizer is not only usable for source objects > > - the XMLizer is extensible... > > fantastic. This brings up another idea I have been playing with > recently. I > have a couple of binary file formats that I convert into SAX events for > further processing... > Yo, that sort of things.
> Maybe it would be an idea to instead create a new package for XMLizer > interface and related implementations. ie I assume that there is a POI > deserializer (or whatever they are called in cocoon) that reads the > excel/word/whatever documents and produces an XML stream (either > as SAX or as > DOM). I have similar readers that deal with other binary > protocols. I also > used to always use a directory to XML producer (I stole idea from > stylebook > IIRC). I am sure other people have other similar demands. (PDF to XML?) > > So maybe a generic framework for converting streams to XML may be > in order ? > Something separate from XML parsing stuff already in place? > The XMLizer itself is intependent from the parser stuff but of course some implementations like the conversion from "text/xml" into SAX events requires a parser. I thought of the package "org.apache.excalibur.xmlizer" resp. "org.apache.excalibur.xmlizer.impl". Carsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
