Andy Clark wrote:
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;
Yes, I agree with Andy. a public void serialize(Node node) throws IOException; method may be all we need to support all the Node objects including Document, Element, DocumentFragment, etc.
Look at the way we implement the dom.DOMWriter public void print(Node node) method.
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.
I will vote for doing without it if we can.
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.
Yes, I think we should rename this class to MimeType and we should use the mime types as suggested by Andy.
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?
I think that this idea has a lot of potential maybe using the TreeWalker method and allowing a way to register a filter then the
serializer could be customized to output user selected nodes.
A user can select and serialize a view of the DOM this way.
SerializerFactory: There's no way to dynamically register OutputMethods or Serializers. I think that there should be a way to do this.
I agree, I think that the SerializerFactory could allow dynamic registration of OutputMethods and/or Serializers.
And overall, I'm not sure if we'd be allowed to drop stuff into the org.xml package namespace. Arkin: have you checked
Yes, we need to figure this out. I think the safest way would be to move this package to the org.apache.xerces namespace Andy, by the way this package is in the org.Apache.xml not the org.xml ( Am i missing something here? ).
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.
I agree, with Andy too. I think that we should be able to have binary and 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
Arghh!! excuse me!! SVG getting serialized to a JPEG image is quite an interesting idea!. What is next, smil files to native realaudio files?
Objects, though. Perhaps a better example would be an XML serializer that outputs to WBXML.
Yes, this is a good idea and I would like so see it implemented. WBXML (binary XML) has a lot of potential specially for embedded devices, cellular phone applications, PDA, etc.
Jeffrey Rodriguez XML Development IBM Cupertino
______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
