Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Playing with the underlying storage

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>, "XOM list (E-mail)" <xom-interest AT lists.ibiblio.org>
  • Cc:
  • Subject: Re: [XOM-interest] Playing with the underlying storage
  • Date: Sun, 4 May 2003 09:49:07 -0400

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



  • Re: [XOM-interest] Playing with the underlying storage, Elliotte Rusty Harold, 05/04/2003

Archive powered by MHonArc 2.6.24.

Top of Page