[
Lists Home |
Date Index |
Thread Index
]
Over the weekend, I spent some time reading through Xalan
documentation and some of its sources. The complexity of the javaDoc
baffled me. I mean I understand XSLT is complex and optimizing it even
more so, and I didn't expect to understand all of the code in one
sitting. I was hoping to understand *how difficult* would it be to
adapt its internal data model to nonstandard use. But the number of
packages, classes, class members and the deep inheritance hierarchies
made the docs difficult to navigate.
The "plain" docs had a number of interesting insights. In particular,
the design document [1] says:
The main goals of this redesign are to:
1.Make the design and code more understandable by Open Source people.
I paused for a while when I read that. And then I decided to see what
"open source people" thought to be "more understandable". 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).
Could there be a drastic difference in complexity, for the same
functionality, depending on the vendor's size? Is it possible that
similar trends exist in specifications as well as implementations?
Ari.
[1] http://xml.apache.org/xalan-j/design/design2_0_0.html#intro
--
"Einstein repeatedly argued that there must be simplified explanations
of nature, because God is not capricious or arbitrary. No such faith
comforts the software engineer. Much of the complexity that he must
master is arbitrary complexity, forced without rhyme or reason by the
many human institutions and systems to which his interfaces must
conform."
Fred Brooks, "No Silver Bullet", 1986
|
