[jsword-devel] OSIS vs JAXB
joe at eireneh.com
Mon May 10 12:29:07 MST 2004
By playing around I discovered that swapping to JDOM is actually quite
easy so I propose that we do it, I've got to a fairly compile clean
state, but it doest actually work, so I'm not done yet.
JDOM might not be the best answer - my thoughts.
Of the 4 types of XML API, we can rule out the Binding types, like JAXB,
Castor and XMLBeans. From my reading JAXB may well be the poorest, but
the will all suffer from the same schema problems and so some extent the
same bloat problems.
Push Streaming APIs like SAX and XNI, and to a lesser extent Pull
Streaming APIs like XMLPull are OK for reading XML, but not for writing
and are fairly hard to use even for reading.
Of the Tree based APIs that are common, DOM has a reputation for being
hard to use and is inflexible in not allowing re-parenting or element
cloning, however this may well have been fixed in recent versions. I
think the JAXP in JDK1.4 still has these problems though.
DOM4J and ElecticXML are supposed to be easy to use but don't often to
the Right Thing from an XML point of view. JDOM has a JSR so it is
likely to be around for a while, and we use it already. XOM is similar
to JDOM, but is leaner, less used and doesn't use Collections.
So my gut reaction is to stick with JDOM. Any comments?
XOM links if you are interested:
Home - http://www.cafeconleche.org/XOM/
OReilly - http://www.xml.com/pub/a/2002/11/27/xom.html
ERH Presentation - http://www.cafeconleche.org/XOM/whatswrong/text0.html
DM Smith wrote:
> As to performance, the dom is full featured so the core is pretty big.
> With large answer sets, we may need to do lazy construction of the
> document. That is as each tab is populated, we build just the document
> for that page. If we do this the core will not grow too large.
We do currently do that. However it occurs to me that one of the changes
that I'd contemplated broke that. I need to remember that.
More information about the jsword-devel