Lists Home |
Date Index |
"Michael Kay" <email@example.com> writes:
> > Here's an observation:
> > [kari@pc-kari kari]$ du -sh $XSLT_SOURCES
> > 9.3M xalan-j_2_4_0/src/org/apache
> > 2.8M saxon6_5_2/source/com/icl/saxon
> > 1.6M xt-20020426a-src/src/com/jclark
> > There are two issues with this that I could immediately think
> > of: (1)XT is incomplete, missing some minor feature which
> > Xalan is reported to support. (2)Xalan includes xsltc, an
> > XSLT-to-Java-bytecode compiler; OTOH, both XT and Saxon
> > include their own parsers, whereas Xalan relies on Xerces
> > (not included in the estimate).
> Size and complexity are different things.
> But I think you will find that on a single-person project (like Saxon or
> xt) there is constant adaptation of existing classes to make them more
> powerful and reusable, and to eliminate duplication, whereas on a
> multi-person project (like Xalan) there is a tendency to try to
How many people *are* on the Xalan team? my impression is that the
core group is quite small.
> implement your part of the system without changing other people's parts,
> even if this leads to duplication.
Looking at the code, it seems that the authors value reuse highly;
inheritance hierarchies 5 and 6 levels deep are commonplace.
But my puzzlement is not over *why did Apache* create a more complex
product than you or James Clark did. It is over the fact that *it is
possible* to create a product that is every bit as functional yet not
> The biggest reason for the discrepancy is probably that the Xalan
> package actually contains two completely separate XSLT processors,
> Xalan-J and XSLTC.
I mentioned that, but it doesn't change the overall picture. And
correct me if I'm wrong on the parser issue. BTW, Xalan and xsltc are
not completely separate; xslt uses the same internal representation as
[kari@pc-kari kari]$ du -sh $APACHE_XML_SOURCES
Xalan-J is still huge.
> One reason that the Saxon source is twice the size of xt is that half
> the lines are comments; James Clark is notoriously averse to commenting
> his code.