Re: Review: Serializer API - the related failure.

[Boris Garbuzov <bo...@keystrokenet.com>]

My notice might be related to the subject. DOMSerializer serializes
newly created Element and DocumentFragment for me, but refuses the root
element, throwing
    java.lang.ClassCastException: org.apache.xerces.dom.TextImpl
      at
org.apache.xml.serialize.XMLSerializer.serializeElement(XMLSerializer.java:577)

      at
org.apache.xml.serialize.BaseMarkupSerializer.serializeNode(BaseMarkupSerializer.java:827)

      at
org.apache.xml.serialize.XMLSerializer.serializeElement(XMLSerializer.java:608)

      at
org.apache.xml.serialize.BaseMarkupSerializer.serializeNode(BaseMarkupSerializer.java:827)

      at
org.apache.xml.serialize.BaseMarkupSerializer.serialize(BaseMarkupSerializer.java:373)

      at
com.keystrokenet.loanproduct.xml.test.Lab.executeTestBody(Lab.java:397)
Is this a bug or my misuse of the API?
------------------------------------------------------------------------------------------



Andy Clark wrote:

> 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 * andyc@apache.org

--
Boris Garbuzov.
Mailing address:
Box 715, Seattle, Washington, 98111-0715, USA.
E-mail: garbuzov@hotmail.com, boris@keystroke.com.
Telephone: 1(206)781-5165 (home), 1(206)576-4549 (office).
Resedential address: 139 NW 104 Street, Seattle, 98177, Wa, USA