inteface Serializer
{
   DocumentHandler asDocumentHandler();
   . . .
}

?

arkin


Stefano Mazzocchi wrote:
> 
> Scott Boag/CAM/Lotus wrote:
> >
> > Stefano Mazzocchi said:
> > > propose to start discussing some XML Output API to propose an addiction
> > > to the proposed Sun's XML Java API that currently lack output features:
> > >
> > > interface Serializer() extends  DocumentHandler {
> > >
> > >    void setOutputFormat(OutputFormat);setOutputByteStream(OutputStream 
> > > output);
> > >    void setOutputCharStream(Writer output);
> > >
> > >    void serialize(Element elem) throws IOException;
> > >    void serialize(Document doc) throws IOException;
> > >  }
> >
> > 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.
> 
> > 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.
> 
> 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.
> 
> It also allows for DOM serialization.
> 
> > > class SerializerFactory() {
> > >
> > >    Serializer makeSerializer(Writer writer, OutputFormat format);
> > >    Serializer makeSerializer(OutputStream output, OutputFormat
> > > format)      throws UnsupportedEncodingException;
> > >
> > > }
> >
> > I'm with Assaf Arken that I would like to see a registerSerializerFactory
> > method on Serializer.  The concept of the SerializerFactory is good.
> 
> Good.
> 
> Stefano.

Reply via email to