XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Lance Eason wrote:

> If you buy the legibility argument aren't you in effect saying then that
> it's okay for other programs to use CDATA sections to create legible
> documents and XOM will even go the extra mile to preserve the legibility
> of those documents but it's not okay for XOM to create similarly legible
> documents?  Just seems inconsistent.  Either CDATA sections are a
> legitimately useful construct in which case it would be useful for XOM
> to support them or they're not in which case there's no particular
> reason for XOM to preserve them.

CDATA sections are a legitimately useful construct for editing. However 
they are not a legitimate part of the infoset, or for any code that 
processes XML documents. XOM is intended as a processing API, not an 
editing API. An XML editor is a very special use case that XOM does not 
support.

XOM attempts to make reasonable efforts to prettyify its output as much 
as reasonably possible, including using CDATA sections where it can. 
However, XOM deliberately does not expose this to the client programmer 
to avoid complexifying the API. People using the API should not have to 
think about this.

This also avoids allowing client programmers to depend on CDATA 
sections. Honestly, the hack you found around this bothers me a little. 
If I can figure out a plausible way to disable it in a future release, I 
probably will. If this breaks any of your code, then your code was 
broken to start with, and you just didn't know it yet. XOM attempts to 
make the right things obvious and the wrong things impossible. Depending 
on the presence or absence of a CDATA section falls into the category of 
the wrong things.

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/