First, I don't really like the term 'Printer' for this functionality. I would rather see something like 'serializer', so, for the moment, I'll use that term in this note.
> 1) put printers inside the parser (as Assaf proposes) > 2) put printers inside the processor (as it is today) > 3) put printers inside FOP > 4) create a new project Well, if you put the Serializers inside Xerces, then Xalan is dependent on Xerces to produce output, which I don't think is a good thing. If you put the Serializers in Xalan, then Xerces becomes dependent on Xalan for output, which is also not a great thing. So I would tend towards #4, creating a new project. (Too bad it's such a big deal to come up with a name...) > Keep also in mind that Xalan has its own Formatters. Please see org.apache.xalan.xpath.xml.FormatterListener, org.apache.xalan.xpath.xml.FormatterToDOM, , org.apache.xalan.xpath.xml.FormatterToXML, org.apache.xalan.xpath.xml.FormatterToHTML, and org.apache.xalan.xpath.xml.FormatterToText. Only having the DocumentHandler interface is not good enough for XSLT. You also need to handle CData, comments, entity references (I see you have something for this), and raw characters (i.e. characters that are not meant to be escaped). If we can handle these I am very much in favor of trying to come up with a common package to handle both XSLT result tree serialization and SAX-to-XML, SAX-to-HTML, DOM-to-XML, etc. I think there's a lot of stuff from both these packages (for instance, we've implemented the URL escaping) that we can combine to create a very robust capability. I would also like to see the code that walks the DOM tree and produces SAX events separated out into it's own class. This is useful in it's own right, and I'm not sure it belongs in a serialization package, though I guess it doesn't hurt that much. In general, I like the structure of the .printer code more than what is currently in Xalan, and think it would be a great starting base. -scott
