XOM API for Processing XML with Java

[Dmitry Katsubo <dma_k AT mail.ru>]

Hi Elliotte!

Thank you for your reply.

On 15.09.2010 13:13, Elliotte Rusty Harold wrote:
> SAX and DOM are supported.

OK, how can I create org.xml.sax.ContentHandler implementation, that
generates XOM tree? OK, I see your answer below...

> Essentialy the supertypes javax.xml.transform.Source and
> javax.xml.transform.Result are useless. You have to cast to the
> subtypes and then use their methods to get anything done, and you
> have to know the subtypes you support in advance.

Yes, I agree with you, that handling of Source/Result classes for
concrete DOM implementation is troublesome and may look ugly. But as
consumer of this API, if target API supports Trax, it really saves me
time and abates the headache. For example, I have a service, that does
something and serializes the XML. In painful case I have:

doSomethingAndSerialize(OutputStream os);
doSomethingAndSerialize(Writer w);
doSomethingAndSerialize(File f);
doSomethingAndSerialize(Node n);
... and so on ...

All these methods I need to put to interface, forward the call (maybe
with minor code) to target API. Also these calls need to be covered by
Utils tests, even though it is simple. All together simply takes time.
And having javax.xml.transform.Result in my hand I announce only one API
call:

doSomethingAndSerialize(Result r);

and all wrappers are in place. Or I need to re-implement a wheel and
write my own implementations, similar to javax.xml.transform.Result
class hierarchy, to wrap / unwrap all kind of targets.

Maybe I do something totally wrong...

> What you need to do is marshal straight to an output stream that is 
> fed into a Builder. Something like
> 
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> marshaller.marshal(bean, out);
> out.close();
> ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());
> Builder builder = new Builder();
> nu.xom.Document doc = builder.build(in);
> 
> You could even do this with piped streams in two threads if you're 
> concerned about the memory footprint of serializing the  entire 
> document into a string.

I did it at the moment via org.w3c.dom DOM, e.g. JAXB->DOM->XOM. I don't
have big XMLs, so I don't worry about garbage collector.

> If this were a common need, I could think about adding support for 
> doing this directly through a ContentHandler.

I am curious (just for my self-education), what are the other ways to
build SAX bridges? Do you have any other API to demonstrate?

> Off the top of my head, I think you're the first person to ask for
> it, and JAXB is the first API I've noticed that used content handlers
> like this. Usually I look for at least two different use cases from
> two or more people before adding something to the API.

OK, of course there should be a real need. Anyway, making XOMHandler /
XOMResult /XOMSource public classes is generally a not bad idea. The
code is there, why not to allow to re-use it?

-- 
With best regards,
Dmitry