Re: Xalan dependent on Xerces?

[Jo...@lotus.com]

There are currently some compile-time dependencies. There shouldn't be any
runtime dependencies.

The IncrementalSAXSource_Xerces class requires that xerces.jar be present
at compile time... but if that fails to compile, no harm is done unless you
later want to leverage Xerces after all; we can fall back on
IncrementalSAXSource_Filter. )The forName stuff in this class is part of a
reflection scheme which is deliberately used to allow us to run cleanly
with either -- or neither -- version of Xerces, and there are fallbacks
which kick in if the class retrieval fails, so that isn't an actual
dependency.)

DTMMangerDefault is testing whether the parser is Xerces or not, so it can
decide which of those two approaches to apply. But that's just testing a
string, so it isn't a compile-time _or_ runtime dependency.

IncrementalSAXSource_Filter should probably be rewritten to instantiate a
SAX parser via JAXP rather than directly creating the Xerces version. But
that statement isn't actually being executed in most situations, so it
probably isn't a runtime dependency. Something to be fixed when someone has
a spare Round Tuit.