>But I still don't think that every call to newTemplates() should
>necessarily require re-compilation - we should at least offer the option
>of caching between sessions.
I suspect what you're trying to emulate is the Java compiler, which is
generally smart enough to load an existing classfile if one is available,
and try to compile the .java file if not. But note that the Java runtime
does _not_ automatically recompile when source changes; it relies on the
user to tell it when to do so. There are environments which do that scan
automatically before starting the application, but that's a higher-level
tool... and in general it has to get the user involved in setting
policies/making decisions about whether the new version is ready to run.
I'd submit that XSLT/XSLTC should probably be handled similarly. Provide
mechanisms to _support_ caching... but let the application, or at least a
higher-level library routine, provide the cache management. Think in terms
of JSP -- the compiler is just a compiler, but the JSP framework provides a
"compile if necessary before loading" behavior and the tools needed to
manage that.
I do think a compilation-cache layer is worth considering. I'm just not
sure pushing it under the TRaX API, rather than wrapping it around that
API, is the best answer architecturally. Among other things, if we do push
it under we need to deal with exposing the cache mechanism via an API so
users can plug in their own policies.
My own preferance would be to prototype this as a wrapper, then move it
internal if/when we're really sure it's general and flexible enough that
people will use it rather than inventing more wrappers.
