This is a long note. I'm looking for guidance on changes to Xalan's
serializer for the XSLT 2.0 features.
I'm working on support for Xalan's serializer (org.apache.xml.serializer)
for new features in the XSLT 2.0 draft and XSLT 2.0 Serialization draft
(e.g. XML 1.1 undeclaration of namespaces).
At the same time I'd like to reduce the visibility of classes in this
package. Right now the official, public, documented way to get a
serializer is to call the
org.apache.xml.serializer.OutputPropertiesFactory.getDefaultMethodProperties(String
method)
to get a java.util.Properties object with default values that you would get
by using the xsl:output method="..." element in a stylsheet, and then use
those properties to call:
org.apache.xml.serializer.SerializerFactory.getSerializer(java.util.Properties
props)
to get a reference to a org.apache.xml.serializer.Serializer object, which
underneath is a an XML, HTML or TEXT "stream" serializer . Other classes
in the package such as ToXMLSAXHandler are used to convert from SAX-like
SerializationHandler events to SAX ContentHandler events.
Right now Xalan-J interpretive and XSLTC know a lot more about the
internals of this package and I'd like to make it less visible to them, and
to end users. The rest of Xalan freely creats ToXMLSAXHandler objects and
others.
What I am thinking about is another factory that would be "public" in the
Java sense, but marked as internal in the javadoc. This would be something
like this:
public abstract class ConverterFactory
{
public static Converter getConverter() {
Converter conv = new ConverterImpl();
return conv;
}
}
//----------------------------------
public interface Converter
{
// OUTPUT CHOICES
public void setOutputFormat(Properties format);
public void setOutputStream(OutputStream output);
public void setOutputWriter(Writer writer);
public void setOutputContentHandler(ContentHandler contentHandler);
public void setOutputLexicalHandler(LexicalHandler lex);
public void setOutputSerializationHandler(SerializationHandler ser);
public void setOutputDOM(Node n);
// INPUT CHOICES
public ContentHandler asContentHandler() throws IOException;
public SerializationHandler asSerializationHandler();
public DOMSerializer asDOMSerializer();
public boolean reset();
}
//------------------------------------
This would be an internal "swiss army knife". One would always call
setOutputFormat. One would call one of setOutputStream, setOutputWriter,
setOutputDOM, setOutputContentHandler, or setOutputSerializationHandler to
set where the output goes. Of the inputs one could call asContentHandler,
asSerializationHandler or asDOMSerializer to provide the input and process
it. In this way one could convert from one of these:
- DOM
- SAX events on the ContentHandler interface
- SAX like events on the SerializationHandler interface
to one of these:
- DOM
- SAX events on the ContentHandler interface
- SAX like events on the SerializationHandler interface
- stream ( to a java.io.Writer or java.io.OutputStream).
Remember this is all "internal".
If things are done through this interface then classes such as
ToXMLSAXHandler will not need to be public. My tendancy would be to make
all the classes in the org.apache.xml.serializer package non-public except
for these:
- ConverterFactory
- DOMSerializer
- ElemDesc ( public but internal)
-EmptySerializer (public but internal)
- Method
- OutputPropertiesFactory
- SerializationHandler (public but internal)
- SerializerFactory
- SerializerTrace
- SerializerTraceWriter
- ToHTMLStream
- ToTextStream
- ToHTMLStream
- ToXHTMLStream
- ToXMLStream
- TransformStateSetter
I think we need to leave ToTextStream, ToHTMLStream, ToXHTMLStream and
ToXMLStream public as users may have extended these classes in the past to
tweak their behavior. On the other hand, maybe I'm wrong on this and no
end users do things like that. I think we should err on the side of
caution.
Your opinons are valued !
Brian Minchau
XSLT Development, IBM Toronto
e-mail: [EMAIL PROTECTED]
