You can't xsl:include a source document, but you can bring it in to the
stylesheet as an external entity:
<xsl:variable name="lookup">
&lookup-doc;
</xsl:variable>
For some processors this might be equivalent to passing in a pre-built tree.
This isn't the case for Saxon, however: Saxon doesn't spot at compile time
that the variable contains no executable instructions, and will rebuild the
tree on each stylesheet execution. It's better to build the tree in your
calling Java application, and pass it to the stylesheet as a parameter.
I've wondered from time to time whether a function such as
document('lookup.xml') should be pre-evaluated at compile time. At present
Saxon doesn't - because it would cause chaos in cases where the contents of
the URL change between compile time and run-time.
Michael Kay
http://www.saxonica.com/
-----Original Message-----
From: Michael Nguyen [mailto:mnguyen(_at_)skolar(_dot_)com]
Sent: 01 February 2005 20:44
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Optimization Question
All,
thanks for all the help. My lookup document (~5MB) is
static. If I
were to do an xsl:include as opposed to me using a document
call, would
using the compilier help? Is there someting I'm forgetting?
--Michael
Robert Koberg wrote:
Michael Kay wrote:
Have you tried XSLTC. This basically allows you to
apply a compiled
form of your stylesheet in your transformations. Both xalan and
saxon ship with XSLT compilers.
...
I'm asked occasionally whether I plan to do a Saxon compiler - more
strictly, a bytecode generator. At present, I don't: I
think it would
slow
down the rate of progress on the product considerably, if only
because code
generators are notoriously hard to debug. I prefer to spend the
effort on
improving the query execution strategies, which can
produce much bigger
potential savings. In any case, I think that for most
people memory
is more
of a constraint than processing speed.
I think this is a good idea. I usually run my app with
Saxon and Xalan
interpretive(?). I occasioanlly run it also with XSLTC and Resin's
compiling processor (which requires much less memory and is the
fastest). I really wish I could use a compiling processor
(especially
resin), but I always fallback to Saxon (its small and fast enough)
because it just works and there is always some little problem I run
into with compiling processors.
best,
-Rob
--~------------------------------------------------------------------
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>
--~--
--
-------------------------------------------------
Michael Nguyen
Senior Software Engineer, SKOLAR
Wolters Kluwer Health - Clinical Tools
1860 Embarcadero Rd, Suite 215
Palo Alto, CA 94303
Phone: 650-354-3025
mnguyen(_at_)skolar(_dot_)com
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--