Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Control output of CDATA sections

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: "Hughes, Rob" <hughes AT fgm.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Control output of CDATA sections
  • Date: Mon, 11 Dec 2006 10:02:14 -0800

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







Archive powered by MHonArc 2.6.24.

Top of Page