> Can't speak for Scott, but here's my own concern: In this
> approach, any code which wants to take advantage of Xalan
> APIs (as opposed to the simplified TrAX view) would have
> to change all its imports whenever it wants to move from
> running against the distributed version to running against
> the development version or vice versa.
This is the case with WebLogic's Xalan (extension element/functions must use the other
classes). This is the case with ours.
One solution (just a thought) would be an org.apache.xalan.ifaces.ExtensionElement
that stays fixed even when people make their own FQCN versions.
If you really want standardization/adherence, this should be specified at the level of
JAXP or something similar. It's probably going too far, but having the equivalent of
javax.jms.Message for XSLT extensions... (Low-level specification really isn't
outside of the scope -- we've got SAX and DOM integrated into the Java XML
"standards", and those are both ultra-low-level.)
> If you're shipping Xalan as part of the internals of an
> application, that probably isn't a problem. If you're
> shipping it as a developer's library, as the JDK is, it
> could be a serious nuisance.
The API differences across versions are sufficient that if someone needs a specific
version of Xalan, then they need that version. It is actually preferable to have
separate internal and external versions so that people can make sure that they get the
version they want and we can make sure that we get the version that we want...
-- Paul
