First, I'd like to look at what's currently in the API and then
discuss some points of design that I'd like to see in the
serializers.
DOMSerializer: I'm sort of surprised that there are methods to
serialize a Document, Element, and DocumentFragment but nothing
for a generic Node. In fact, if you wanted to serialize a text
node or entity reference, you would first have to remove or
clone it into a DocumentFragment and serialize that. And it is
impossible to serialize things like attributes outside of their
container elements. Would it be enough to have the following
method?
public void serialize(Node node) throws IOException;
Method: I don't see a need for this class. If all it's doing
is holding string constants, then I would say get rid of it
completely. Otherwise, make it a Java "enumeration", like so:
public class Method implements Serializable {
// Constants
public static final Method XML = new Method("text/xml");
public static final Method HTML = new Method("text/html");
public static final Method Text = new Method("text/plain");
// Data
private String type;
// Constructors
protected Method(String type) { this.type = type; }
// Object methods: equals, hashCode, and toString
}
But I think that we could do without it altogether and just
make it possible to register new methods with the serializer
factory. But I'll get to that in a minute.
And the type of the method could be the mime type which would
avoid the need of a set/getMediaType on the OutputFormat object.
And if this thing is really representing the mime type, perhaps
it should be called such instead of "Method". It would tie in
better with existing standards.
OutputFormat: It seems like a good idea to have a kind of
properties object like OutputFormat. But it seems that the
OutputFormat (and in fact the whole serializer API) is based
on serializing to a text markup syntax. This sort of jumps
the gun on what I'd like to say in general about the
serialization API so I won't go any further at this point.
Check out my comments below regarding this matter.
Serializer: I noticed that this design makes use of the SAX
interfaces but not of the traversal APIs added with DOM Level
2. Is there a way that we could leverage those interfaces?
SerializerFactory: There's no way to dynamically register
OutputMethods or Serializers. I think that there should be
a way to do this.
And overall, I'm not sure if we'd be allowed to drop stuff
into the org.xml package namespace. Arkin: have you checked
on this? And will any of this be superceded by DOM Level 3?
at least on the DOM serialization side, that is... Perhaps
Arnaud or someone else on the W3C commitee can shed light
on this.
Okay, now I'd like to make a few comments about what I'd
like to see in a serialization API. First, I don't strictly
see serialization as an output to some text markup. As
such, I would like a split between binary and character
serializers. Currently, there are both setOutputStream()
and setWriter() methods on the Serializer objects. If
possible, I'd like setOutputStream() only be on binary
serializers and setWriter() be used on character serializers.
All of the current serializer implementations (XML, HTML,
XHTML) would be character serializers and the OutputFormat
object seems to go very well with this. On the binary side,
however, I can see a situation where SVG gets serialized to
a JPEG image. I realize that this overlaps XSL Formatting
Objects, though. Perhaps a better example would be an XML
serializer that outputs to WBXML.
Is anyone else thinking along these lines?
--
Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED]
