[jsword-devel] OSIS vs JAXB

[Dickinson Smith]

My thoughts: If it is easy, then go for it. For the
cost we get the gain of fault tolerance and smaller
footprint. And *if* there are performance issues, then
we can handle them later.

Since we are using it to construct documents a page at
a time, I don't think it will be a problem.

--- Joe Walker <joe at eireneh.com> wrote:
> 
> 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
> 
> Joe.
> 
> 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.