XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

On Dec 11, 2006, at 7:22 AM, Hughes, Rob wrote:

> Wolfgang,
>
>    I tried your work-around and it does seem to work. But I think I am
> missing something. What if someone wanted to use the streaming StAX  
> API
> and wanted to preserve CDATA sections?

With the underlying StAX API you can do that via  
XMLStreamWriter.writeCData(). As is often the case, for increased  
control, you'd just have to step down to the next abstraction level  
below.

> Wouldn't they be unhappy with the
> CDATA sections being removed?

Perhaps, but I figure most people would be happy to have a less  
complex API that minimizes the need to deal with syntax sugar.

> From other posts I have read, it seems the argument goes that CDATA
> sections are just syntax sugar.

Right. That's the main thread.

> I agree with the argument, but in this
> case I am left with the uncomfortable feeling that things just  
> happened
> to work out in my favor.

CDATA just doesn't appear to be a commonly requested feature. It has  
its uses, sure, but still, inessential things tend to get  
rationalized away over time, or at least relegated to an abstraction  
layer below.

XOM's CDATASection class isn't public. XOM uses class CDATASection  
for cosmetics in specific round-tripping cases. But it's an  
inaccessiable XOM-internal class. In which circumstances it is used  
in exactly which way is essentially undocumented. For example, does a  
Builder coalesce adjacent PCDATA and CDATA nodes into a single XOM  
Text node? How about XPath results and cloning/copying? The source of  
nu.xom.XOMHandler et al will tell you but there's no public contract,  
thus implementations may vary in behaviour. I tend to think that not  
having a contract wrt. CDATA is probably good.

> I'll gladly take the performance gain though.

Here's a corresponding plot (look for Tree Serialization with xom-V  
and xom-stax-wood):
http://dsd.lbl.gov/~hoschek/tmp/plots-stax2.pdf

The numbers are slightly outdated by now, but the overall character  
remains the same for the most recent software versions.

Wolfgang.

> > -----Original Message-----
> > From: Wolfgang Hoschek [mailto:wolfgang.hoschek AT mac.com]
> > Sent: Friday, December 08, 2006 3:34 PM
> > To: Hughes, Rob
> > Cc: xom-interest AT lists.ibiblio.org
> > Subject: Re: [XOM-interest] Control output of CDATA sections
> >
> > If the receiving side of the pipe can't be fixed, a
> > work-around would be to use the StreamingStaxSerializer class
> > in combination with a StAX implementation such as woodstox.
> > It converts XOM's CDATASection objects to StAX character
> > events, which correspond to XOM text nodes.
> > A benefitial side effect of doing so with woodstox would be
> > that serialization is at least twice as fast as with the
> > normal nu.xom.Serializer (measured using no pretty printing).
> >
> > See http://dsd.lbl.gov/nux/api/nux/xom/io/StreamingSerializer.html
> >
> > Example usage:
> >
> > nu.xom.Document doc = ...
> > OutputStream out = ...
> > XMLStreamWriter writer = XMLOutputFactory.newInstance
> > ().createXMLStreamWriter(out, "UTF-8"); StreamingSerializer
> > ser = new StreamingSerializerFactory
> > ().createStaxSerializer(writer); ser.write(doc); out.close();
> >
> > Wolfgang.
> >
> > On Dec 8, 2006, at 6:51 AM, Hughes, Rob wrote:
> >
> > > Is there a property on the XOM serializer to instruct it
> > not to output
> > > CDATA sections?
> > >
> > > I have an application where the XML instance documents are
> > not allowed
> > > to contain CDATA sections. As a result, it is important for
> > me control
> > > this aspect of the serializer.
> > >
> > > --Thank You, Rob
> > > _______________________________________________
> > > XOM-interest mailing list
> > > XOM-interest AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/xom-interest