[jsword-devel] OSIS vs JAXB
dmsmith555 at yahoo.com
Sun May 9 16:16:30 MST 2004
I think that jaxb is unnecessary bloat. It is a nice idea but it suffers
from the problems that you mention. The gains don't seem like a
sufficient benefit to me.
I have not spent a lot of time looking at the code, but it seems to me
that osis can be used at two points.
The first is a source text that is encoded osis. The problem I see with
using jaxb with this is its lack of fault tolerance. If the source text
does not match the schema (for example it is 2.0 when we are at 1.x)
then it will bomb. It may be best to build the document without validation.
For each encoding there needs to be a translator that is able to
translate it to the form that the rest of JSword expects.
Second, osis is useful as an intermediate form that all source text is
transformed into. I really like that this is what JSword does.
In examining the transformations, it manually builds a document bit by
bit. I have used the dom interface to do this directly. It looks pretty
much like the same code as the jaxb. The big difference is that jaxb
uses objects that are named after the elements. Whereas dom uses a
create element method that takes a name. In either case, the impact is
that to produce an osis compliant document means that the code will need
to be re-written if the schema of osis changes. The only way around this
is to roll your own or don't upgrade. Which I don't advocate.
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.
Joe Walker wrote:
> We've discussed this before, but I'm wondering if we made the wrong
> decision in going to JAXB. I think there are 2 questions we need to
> 1. Should we change, and what to?
> 2. If we do decide to change should we do it before 1.0?
> The problems with JAXB are:
> - Download size. As of OSIS 1.1 the generated classes weigh in at about
> 1Mb and the jar files that depends on come to about 4Mb!
> - Lack of non-validating mode. This is a problem for 2 reasons, Sword
> modules (and probably those from other sources too) are not valid OSIS,
> and the spec changes, and we could be left having to use several XSDs
> which would make the code complex and huge.
> - Minor niggle, JAXB does not give you a getParent() method which is
> very annoying.
> - The license isn't OSS although it does allow redistribution.
> My guess is that swapping JAXB to something else (JDOM being obvious
> because we use it already, but we could think about DOM4J. XOM,
> XMLBeans, etc) would be a day or 2 of total carnage, followed by
> something potentially slightly slower, but a lot smaller and far more
> jsword-devel mailing list
> jsword-devel at crosswire.org
More information about the jsword-devel