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@xxxxxxxxxx] 
> Sent: 01 February 2005 20:44
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> 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
> 
> 
> -- 
> -------------------------------------------------
> 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@xxxxxxxxxx