[
Lists Home |
Date Index |
Thread Index
]
> > The common problem that arises here is that someone has a 500MB XML
> > catalog and their machine bombs when they try to transform the whole
> > thing at once. So they write a SAX reader that grabs each "author"
> > element and transforms it individually using a cached XSLT
stylesheet.
>
> This is in effect what Saxon's saxon:preview extension does for you.
Yeah, that beats asking the user to write their own SAX filter, but
still requires some level of collusion with the stylesheet developer.
> limited, though it might become rather more feasible if the optimizer
has
> knowledge of the schema. It only takes a single template that uses
"..",
Definitely schema is an area where the optimizations could be discovered
more accurately.
> make the optimization invalid, unless you know for certain that these
are
> only selecting within the current subtree.
Exactly, this is the point of "forward-only XPath". In essence, you are
figuring out which XPaths in which contexts are going to be "only
selecting within the current subtree." And of course the "chunking" is
artificial, so another way to look at it is "what is the smallest chunk
size that allows all relevant XPaths to take place within the context of
that chunk?" It's not an *easy* problem to solve, and in many cases the
answer will be "the whole document". But this is just my guess as to
why the original poster was relating forward-only XPath and XSLT.
>
> Mike Kay
smime.p7s
|
