XOM API for Processing XML with Java

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

Wolfgang Hoschek wrote:

> How can a main memory tree (and the binary codec is no exception) 
> address documents growing faster than moore's law? Cause that's the 
> technology drift happening at the "very large document" area. A very 
> large document an app is processing today won't have the same size in 6 
> months. Can one trim XOM memory faster than that rate in a sustainable 
> manner? Certainly not. Can one trim XOM memory to zero, which is what it 
> would need to be to handle arbitrarily large documents? Certainly not.

You're repeating the binary fallacy. You're saying anything less than 
perfect isn't worth bothering with. Of course we can't trim memory usage 
to zero. But I do think every significant reduction in memory usage we 
make does expand the universe of documents XOM can handle.

> It goes without saying that consuming exorbitant amounts of memory for 
> no good reason is always a bad idea. So trim memory fat where it 
> improves or doesn't hurt performance, and abstain from trimming where it 
> would degrade performance.

As I've said before, I encounter far more developers having trouble with 
XML due to memory usage and document size than due to speed, and as you 
point out Moore's law does a better job of solving speed problems than 
size problems. Where a choice needs to be made between optimizing for 
size and optimizing for speed, I will optimize for size. If XOM can do 
both, great; but when forced to choose size is more important to more users.

--
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