Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Text.java path for optional builds

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Text.java path for optional builds
  • Date: Sun, 19 Dec 2004 08:06:36 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page