We need to include this on the Xalan dev list, or move it up to the general list.
> There's need for the printers to be available for XML parser users. The > printers in Xalan required a separate download, are very well hidden > (took me two attempts to locate them because I knew they were there!), Totally agreed. > The exisiting code base deals with CData (setCDataElements) and raw > characters (setUnescapedElements). Yep. Sorry, I missed it the first time around. > There are also event handles for > comments and entity reference but these only work for DOM right now. No > problem adding a DocumentHandlerEx to make them available for SAX. Great! > I totally agree we need a separate tree walker. In my opinion there > should be a set of generic utility classes, including DOM->SAX, > SAX->DOM, whitespace handling, namespace stripping, etc. Yeah, but, again, not sure these should go into Xerces. > I assume most users who > download Xalan also have Xerces installed, I don't think this is a good assumption. In my view we are making components, which should be standalone. For instance, Xalan is useable without any parser at all, though this tends to be an unlikely scenario. It is certainly designed not to have tight coupling with Xerces. That said, in order to get this off the ground, I could live with it being in the Xerces package for the time being. > or can obtain the > printer/utility packages separately. Not sure what you mean by this. > In my understanding FOP implements > it's own printer that requires the FOP code base I don't think there's any question that it shouldn't go into FOP. But FOP may want to implement the basic factory interfaces, without being dependent on Xerces. What do you think about changing the package name from .printer to .serializer or .xmloutput or the like? We'll also need a raw text output. I can adapt my FormatterToDOM to use straight SAX, so this won't be a problem. -scott
