This discussion is totally over my head ;-) In my understanding the serializer is has one of three methods:
* A way to specify the output format and output target * A way to serialize a DOM tree * A way to retuirn a DocumentHandler that can be fed to an event source Ce tou. The fact that I chose to extend specific serializers from BaseSerializer which supports both SAX and DOM is an implementation, not API, decision. It keeps the code base more compact, the different handling are grouped together, bugs are easier to spot and fix across both parsers. It could be implemented any other way, and other serializers do not need to extend BaseSerializer. They only need to implement the Serializer interface. arkin Scott Boag/CAM/Lotus wrote: > > >> I'm not sure what the point to this is. The whole point of > DocumentHandler > >> is that you don't want to know that it is serializing, constructing a > DOM > >> tree, or doing something totally different. > > > > Correct. The whole point of extentions is to add features inheriting the > > old ones. > > While it may be convenient for the DocumentHandler and the Serializer to be > implemented in the same object, it is my no means necessary or helpful, if > you pass the DocumentHandler object to the serialize method. > > If you want to change Serializer from an abstract class to a interface, I'm > just not sure of the value of making it derive from DocumentHandler, and it > seems to me that it limits it. Now, when I want "serialize" to any old > DocumentHander, I have to get the method from that object, which seems > incorrect. I would rather assume the functions of "consuming" and > "feeding-input-to-consumer" are separate. > > In general, I don't think the same object that consumes should be expected > to process the input (i.e. walk the DOM tree). > > >> I don't know what is gained by > >> making the Serializer interface an extension to DocumentHandler. > > > > because a DocumentHandler, like you said, doesn't have a clue on what > > it's doing. The DocumentHandler caller doesn't care, but you _do_ care > > about where the serialized data is going. > > Right. Nor should the DocumentHandler care. Which is why I don't see a > point to adding a Serializer derivation of the DocumentHandler. > > > So, like the interface clearly states, a Serializer is a consumer, so > > implements DocumentHandler, but it serializes on an output stream with > > the given output format. > > Ignoring the factory methods, the Serializer is a "input-to-output-feeder", > rather than a consumer. It is feeding the input to the consumer, and is an > operation with two parameters: the input and the consumer. > > BTW, the more I have used the serializer classes, the more I think the term > "Serializer" was a mistake for the Serializer class. While the > BaseSerializer class and derivatives clearly deal with serialization, the > Serializer abstract class can and should be used with any output operation. > I'm not suggesting a change for the near term, but it is food for > thought... > > > It also allows for DOM serialization. > > Right, another reason why I wouldn't like to see a serializer derivation > from a SAX interface. Note the serialize methods *only* walk the DOM, and > the rest of the methods are factory interfaces. Not that Xalan does not > use any of the serializer methods, because it must already have DOM visiter > functionality (TreeWalker) outside the context of Xerces serialization, and > so just uses that. If the serializer methods in Serializer and the > implementation in BaseSerializer were broken out into a separate class, I > might be able to use those, and throw away my TreeWalker class. > > -scott
