XSLT is not a programming language! Just so you remember.
XSLT is a declarative language and can be used by you to describe
what you want put in your output document and
what you want this output to look like. It does not describe
how these tasks should be carried. That is the job of the XSLT
processor. This document is not a "programmer's guide to XSLT"
and should not be considered as such. All XSLT processors have their
properties and ways of handling XSL elements and XPath properties. This
document will give you some insight into the XSLTC internals, so that you
can channel your stylesheets through XSLTC's shortest and most efficient
XSLTC's performance has always been one of its key selling points.
(I should probably find a better term here, since we're giving XSLTC away
for free.) But, there are some specific patterns and expressions that are
not handled much better than with other interpretive XSLT processors, and
this document is an attempt to pinpoint these and to outline alternatives.
All XSLT processors use an internal DOM-like structure, and XSLTC is no
exception. The internal DOM is tailored for the XSLTC design and can be
navigated efficiently by the translet. Building the internal DOM is a
rather slow process, and does very many cases take more time than the
actual transformation. This is a general rule, and does not only apply to
XSLTC. It is advisable, and common in most large-scale XSLT-based
applications, to create a cache for the input documents. Not only does this
prevent CPU- and memory-intensive DOM creation, but it also prevents several
translets from having their own private copies of common input documents.
Both XSLTC's internal API and TrAX implementation provide ways of
implementing a decent input document cache:
- See below for a description of how
to do this using the TrAX interface.
- The native API
documentation contains a section on using the internal
An extension to the TrAX API allows input documents to be cached. The
extensions is a sub-class to the TrAX
Source class, which can
be used to wrap XSLTC's internal DOM structures. This is described in
detail in the XSLTC TrAX API reference.
If you do chose to implement a DOM cache, you should have your cache
javax.xml.transform.URIResolver interface so
that documents loaded by the
document() function are also read
from your cache.