[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: how much complexity is unavoidable?

• To: <xml-dev@l...>
• Subject: Re: how much complexity is unavoidable?
• From: ari@c... (K. Ari Krupnikov)
• Date: 19 Nov 2002 22:18:33 +0000
• Cc: <michael.h.kay@n...>
• In-reply-to: <001901c28f1f$81a4e220$6401a8c0@pcukmka>
• References: <001901c28f1f$81a4e220$6401a8c0@pcukmka>
• User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

"Michael Kay" <michael.h.kay@n...> 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
as complex.

> 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
Xalan, DTM.

[kari@pc-kari kari]$ du -sh $APACHE_XML_SOURCES
9.3M    xalan-j_2_4_0/src/org/apache
2.9M    xalan-j_2_4_0/src/org/apache/xalan/xsltc
7.3M    xerces-2_2_1/src/org/apache

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.

• Follow-Ups:
  • RE: how much complexity is unavoidable?
    • From: "Michael Kay" <michael.h.kay@n...>

• References:
  • RE: how much complexity is unavoidable?
    • From: "Michael Kay" <michael.h.kay@n...>

• Prev by Date: RE: Namespaces and XML Schema validation
• Next by Date: XSL transformation
• Previous by thread: RE: how much complexity is unavoidable?
• Next by thread: RE: how much complexity is unavoidable?
• Index(es):
  • Date
  • Thread