[jdom-interest] a CDATA implementation

Oliver Imbusch flabes at livis.de
Sat Aug 26 02:09:03 PDT 2000

>>>>> "ds" == Dan Schaffer <dan.schaffer at time0.com> writes:
>>>>> "jh" == Jason Hunter <jhunter at collab.net> writes:

    ds> The project takes user maintained xml files as input and some
    ds> of the elements contain series of html tags and servlet urls
    ds> (full of <,>,&).  Users often use CDATA sections to keep the
    ds> text readable and they were not too happy when I changed their
    ds> pretty "<![CDATA[<html><head>]]>" patterns into
    ds> "&lt;html&gt;&lt;head&gt;".

That's exactly where I like the CDATA: human-readable (and editable)
XML files.

    ds> I added a class called org.jdom.CDATA

That's where I don't like it: in the JDOM tree. As Jason points out in
another posting:

    jh> All content can be represented without the use of CDATA (it's
    jh> just a shorthand for avoiding char entities), and since adding
    jh> a CDATA class would complicate the API, we currently don't
    jh> bother with it.

When dealing programmatically with JDOM nodes, I don't like to see any
CDATA. I think CDATA support should go to the in-/outputters. An
inputter should support CDATA unconditionally and convert it to plain
text. An outputter could decide whether to write CDATA or plain text
depending on the node content (eg if newlines or tabs are enclosed, or
if '<', '>' or '&', or if any character should be escaped, etc) in a
configurable fashion.


More information about the jdom-interest mailing list