+1, why not use XSLTC today?
I have this kind of setup:
A -> B -> C
Stylesheet A imports B, which imports C.
B and C are both reasonably large stylesheets. A is generated per
request, is quite small and overrides specific templates in B or C
depending on the requirement. I keep compiled copies of B and C in
memory, so when A is not needed I can just use the compiled version.
However, when A is needed, B and C must be parsed and built
each time.
[snip]
well, you have the ability to do this with XSLTC today?
In my particular case, stylesheet A is generated from another stylesheet
per request. It's not static. Can XSLTC help me here? (I'm also using
2.0 now...)
I think concerns about portability remain, and might be
useful to discuss in the context of packaging, compiled
stylesheets, function libraries, and so on.
Why not just complile up a version of your stylesheet for each processor
that's likely to use it? Compiled stylesheets for me are all about
performance, not portability.
cheers
andrew
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--