Re: [xsl] XSLT streaming: the processor "remembers" things as it descends the XML tree?

Subject: Re: [xsl] XSLT streaming: the processor "remembers" things as it descends the XML tree?
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 20 Nov 2013 11:23:34 +0000
On 20 Nov 2013, at 10:42, Costello, Roger L. <costello@xxxxxxxxx> wrote:

> Hi Folks,
> Consider an XSLT program that is at some node. The XSLT streaming rules say
that the following nodes are accessible from that node: its ancestors and
their attributes and namespaces, and its descendants and their attributes and
> If my XSLT program accesses ancestor nodes, that seems to require the XSLT
processor to back up. And isn't that a violation of the fundamental law of
streaming, "The XSLT processor shall not back up"?
> Or, perhaps my XSLT program can access ancestor nodes because, as the XSLT
processor descends the XML tree it keeps a record of each node through which
it descends (the node's name, its attributes, its namespaces). Yes, that must
be what the XSLT processor does. Suppose that my XML tree is very deep, then
the XSLT processor will have to remember a lot of stuff, right? In the extreme
case, every node in the XML document has no siblings, just one child. Thus,
the XSLT processor would have to remember the entire XML document, right?
> Questions:
> 1. In XSLT streaming the processor "remembers" things as it descends the XML
tree, right?

Yes, a streaming processor essentially maintains a "slice" through the tree, a
moving stack, containing the context node and the start tags of all its
> 2. In XSLT streaming, allowing access to ancestors seems like a bad idea,
for the reasons described above. What is the rationale for allowing access to

It's based on the use cases we studied, where (a) access to ancestor nodes was
found to be useful, and (b) in all the examples of very large documents that
we studied, we found that the maximum depth of the tree did not increase
sufficiently to create a concern about the amount of memory needed. Unlike
some researchers, we have always been driven by typical use cases and not by
worst-case scenarios; the case where tree depth increases linearly with
document size is a theoretical worst case that simply doesn't arise in

Michael Kay

Current Thread