Hi,
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com]On Behalf Of
Michael Kay
Sent: Wednesday, September 25, 2002 4:19 AM
Another memory related issue: It would be a great thing if
the processors could separate out and cache just once
xsl:includes/imports and some link them into a Templates object.
...
I know I asked about this a year or so ago and it was not
possible then (Saxon and Xalan). Is this possible today?
It's certainly possible in theory. However, I think a very considerable
amount of the work that's currently done at compile time would end up
being done at link time, so linking the modules dynamically for each
transformation might not give great performance.
I was not thinking of linking them dynamically. When compiling the primary XSL,
you know what includes are present. I was wondering if there was some way to
statically link the includes so it would mimic a fully compiled XSL, but still
keep it separate for memory purposes. Of course, I don't know how to do this :)
I'm currently working on a different approach, which is to make sure
that all the unused variables, templates etc from imported modules are
discarded from the compiled stylesheet. This creates a few problems for
things like saxon:evaluate(): which actually confirms the reasons some
implementors were reluctant to put an evaluate() function in the spec.
Isn't this totally dependant on the source XML? How can you know which variables
and templates will be unused if you are making the decision at compile time?
Wouldn't you need the source and any XML brought in through the document
function?
I assume everyone strives to only write XSL that has what they need. I don't
always need every template for every transformation, but when I need it, I need
it. Most likely, I am missing something here??
best,
-Rob
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list