XOM API for Processing XML with Java

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

At 11:51 AM -0600 4/10/03, Trimmer, Todd wrote:
> Let's say three different systems use XML in wildly different ways:
>
>
> System 1 often concentrates on a large group of sibling elements at one
> time. It does sequential reads and random access reads by position.
> ArrayLists behoove it.
>
> System 2 does a lot of adds of new Elements and removes of old Elements
> under the same parent. LinkedLists behoove it.

I wouldn't assume this. ArrayList (which XOM uses internally) is 
shockingly fast for this, and may outperform LinkedList. The 
implementation of ArrayList moves large chunks of memory around as 
necessary rather than copying and moving items in the list one by one.

> System 3 does a lot or random access by tag name and/or attribute value (key
> lookup). Maps behoove it.

Is there such a thing as an ordered Map? And what if you need to map 
by multiple different values? I think what you really need is 
internal indexing. I doubt a plain map would help that much.

However, although I don't believe these use cases are compelling, I 
do think there are good and valid reasons for wanting to change the 
storage engine (e.g. a native XML database). But so far I don't see 
how to do this within XOM. I think I have to tell people who want to 
do this to consider DOM instead.

> What if there was an OM that let you at parse time request what type of
> storage the Nodes will be placed under? The same operations would exist
> under each of them. You can still use solid classes; no need for interfaces.
> What would the ramifications be? Would the Documents become interoperable?
> Would they fall under the same serialization curses that DOM did?

Interesting thoughts. I can't see pulling this off within the limits 
of Java, while still keeping the internal code base manageable and 
continuing to use classes that enforce constraints. To really pull 
this off I'd need some powers that Java just doesn't give me. Either:

1. Inheritable preconditions, postconditions, and class invariants as 
in Eiffel so more detail of implementation could be left to the 
subclasses while still maintaining all constraints.

2. Friend functions or alternately sub-package access to package 
protected parts of superpackages. e.g. nu.xom.maps can see the 
internals of nu.xom.

Without one of these features, I don't think changing the underlying 
storage model in subclasses is plausible.
--
Elliotte Rusty Harold
elharo AT metalab.unc.edu
Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA