XOM API for Processing XML with Java

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

FYI,

I am thinking about this. It's a reasonable thing to do, and I would 
like to provide some sort of switch that selects between a 
speed-optimized and a space optimized XOM. Ideally I'd like that to be 
settable at runtime or even on a per-document or per-builder basis. 
However, do far I haven't come up with any such approach I like so a 
compile time switch might be the best option.

I'm not sure if this build file approach is the right way to do this 
compile time switch or not, or if it needs to be tweaked in some way. 
Further thoughts and suggestions about that are appreciated.

One thing that does concern me is testing. Testing gets exponentially 
complex with each extra compile time option we add. There are actually a 
lot of hidden options already: what parser is in the classpath; what 
version of the JDK is being used; what platform the tests are running 
on, etc. Some of the tests deliberately turn themselves off in certain 
environments where they don't really apply. Actually testing every line 
of code in XOM requires running on at least two platforms and with at 
least two different versions of Java, possibly more. JUnit doesn't 
really handle this very well. or at all. :-( If we add this I'd like to 
be able to automatically run all tests with both versions of the Text 
class. I'm not sure how easy that would be to do. It would roughly 
double the amount of time required to run the test suite though.

There is another thing that concerns me. Hidden in my pantry is a 
serializer that's significantly faster than XOM's default serializer. It 
gets the extra speed by offering no options. It just serializes the 
document in straight Unicode, without any indenting or other issues. 
I've been debating how or whether to introduce it. The proposed patch 
might slow that serializer down since it would require converting the 
strings to UTF-8, rather than just blasting the UTF-8 onto the 
OutputStream.

Any way, as I said this is on my radar screen. Possibly it will get 
deferred into 1.0.1, or possibly it will make it into 1.0 if I can be 
convinced of the "right" way to do this before the XInclude working 
group finishes XInclude 1.0 recommendation, which is the major remaining 
blocker for 1.0. By the way, John, any progress on that front? Either 
way, since this proposal doesn't affect the public API, I can roll it in 
later even if it doesn't make it in now.

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim