> This doesn't need to be, and shouldn't be, IMHO, part of the Serializer > interface. If I want to create a DocumentHandler that serializes, and > implements setOutputStream, why should I also have to implement serializer > methods that take a DOM node, when there are plenty of other classes that > walk the DOM and produce SAX events?
A serializer can implement DOM printing faster than walking the DOM and producing SAX events. You are worried about XSL efficiency, other people are worried about DOM efficiency. If you ask BaseSerializer to print a DOM document or element directly, it will be way more efficient than walking the DOM tree and firing SAX events. (And no, it does not fire events internally, it does not create a new attribute list for each element, and it prints strings directly without transforming them to character arrays) > > * A way to retuirn a DocumentHandler that can be fed to an event source > > This is really a factory method. No, it's just a way to obtain an implementation of an interface. Serializer.asDocumentHandler() could return this, or it could return some other object but always return the exact same object. It's just a way to get a DocumentHandler without Serializer having to extend one. > Exactly. My point is that something like setOutputStream does not need to > be in an interface that derives from DocumentHandler. I'm not following you on that one. Can you just write down how you think the interface should look? > > -scott
