This ties back into the "filtering" optimization proposal that we've
discussed in the past. It would definitely be a good thing if an XSLT
processor could cross-analyse a stylesheet against a schema or DTD and
ignore/discard portions of the source document which definitely won't be
referenced. Of course in the general case this is another flavor of the
stopping problem, but certainly many simpler versions of it could be
recognized and leveraged.
Certainly promising, and worth investigating. But it's an optimization
which we haven't yet implemented, and doing it well requires fairly deep
analysis of the stylesheet's structure.
The most promising idea I can offer you right now is the DOM2DTM2 classin
the xslt20 branch. This is a more incremental version of the adapter from a
DOM model to our internal DTM APIs; one of its advantages is that it can
support completely out-of-order construction of the DTM wrapper. If your
custom model can filter dynamically -- ie, if it can build out-of-order
rather than needing all its filtering criteria supplied before it starts --
then a similar out-of-sequence DTM adapter wrapped around it might have the
results you're looking for, allowing you to construct only those subtrees
which the stylesheet actually references. (In fact, one of the reasons
we've been looking at possibly moving from DTM to the cursor-based XDM
concept is that XDM may be better suited to just this kind of access.)
However, one downside of out-of-order construction is that it tends to make
comparing the document order of nodes (which XSLT sometimes has to do) more
expensive, unless that information has been recorded at a lower level. So
there's a performance trade-off here.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
