[
Lists Home |
Date Index |
Thread Index
]
> What if you avoid such constructs? What if all your
> expressions only select
> along the child and attribute axes -- are existing XSLT
> engines (SAXON, for
> instance) smart enough to optimize for that and not try to
> hold the entire
> document structure in memory?
No, I don't think any existing processors do this optimization, and for a
good reason: there aren't enough stylesheets that meet all these constraints
to justify implementing it.
The constraints you've listed aren't a full set. For example using last()
invalidates serial processing, as does <xsl:number/>, as do id() and key()
and any absolute path expression. Positional predicates such as [1] in
patterns are do-able in theory but not easy. It's not enough that a template
rule should only select children and attributes, it must only do one
downwards selection, i.e. it must only have one for-each or apply-templates
or value-of or copy-of instruction that processes children (though it can
have any number that process attributes). In other words, it's basically a
subset of XSLT that can do nothing other than subsetting and renaming the
elements in the source document in a context-free way.
At one early stage Saxon did have a serial processing mode. It was so
different from the normal processing mode that the software architecture was
really suffering from having to support both, so I scrapped it, replacing it
with saxon:preview. Even saxon:preview causes maintenance headaches from
time to time.
Xalan, I think, has introduced a processing model in which transformation is
done in parallel with parsing, and I think this architecture was introduced
with a view to discarding parts of the tree that are known to be no longer
needed. So they've got an architecture that's capable of doing it, but they
probably need to do a lot more static analysis of the stylesheet to be able
to complete the job.
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
|
