Balisage Paper: In pursuit of streamable stylesheet functions in XSLT 3.0

Approach 1: analyzing stylesheet functions statically on their own

Arguably the easiest approach from both the user's point of view and for implementors alike is to try to find a method to analyze the streamability of stylesheet functions statically, without taking into account any possible context the stylesheet function is called in.

Suppose you have a stylesheet function my:for-each which traverses all nodes in a node set and returns a certain aggregate result. By its definition, traversing the node set, it will consume the input tree, just like xsl:for-each would. Writing such a function that it works equally well for different kinds of input postures is hard, perhaps even impossible. A function call like my:for-each(head//section) may have to traverse over overlapping nodes, the expression in the argument is a crawling expression and looping over a crawling node set is not allowed in streaming because certain buffering is required to cache the overlapping nodes. If the loop is not going to consume the individual nodes, this is alright^[9], but otherwise, it is not guaranteed streamable.

For such a function to be statically analyzable without knowing what context it is used in, it is allowed to traverse the input tree, but it is not allowed to consume the individual nodes of the streamed input tree. A function that can potentially work with any input posture, albeit climbing, striding or crawling might look like the following:

<xsl:function name="my:for-each1">
    <xsl:param name="$node-set" as="node()*" />
    <xsl:for-each select="$node-set">
        <xsl:sequence select="./@name" />
    </xsl:for-each>
</xsl:function>

This example loops over all the nodes, but does not consume the individual nodes, it only requests a property of those nodes using the attribute axis, which is motionless and its result is climbing. And a motionless expression on either a climbing, striding or crawling context is always allowed^[10].

Even though this example is exemplary for showing the possibility of writing a function that can take any posture, it limits our possibilities greatly. Suppose we want to write an implementation of my:for-each that does consume the individual nodes in the streamed node set, for instance as in the following example:

<xsl:function name="my:for-each2">
    <xsl:param name="$node-set" as="node()*" />
    <xsl:for-each select="$node-set">
        <xsl:value-of select="child::*[self::author | self::author-name]" />
    </xsl:for-each>
</xsl:function>

Whether or not this example would use the child axis within the xsl:for-each or directly without the loop, for the streamability analysis this does not matter. The child axis, if applied on a climbing or crawling axis, is always roaming and has a sweep of free-ranging^[11]. This means that the expression my:for-each2(child::book) is allowed, but the expressions my:for-each2(listing//book) and my:for-each(title/ancestor::book) are not, because the latter two have arguments with crawling and climbing postures respectively and can therefor not be consumed.

This leaves us with essentially two options for static analysis of streamable stylesheet functions, without having to take the function calls into account:

Both options have severe drawbacks, but they have the advantage of being very clear-cut and easy to communicate or explain. As it turns out, the current approach taken by the XSL Working Group, as explained in XSL Bug 25679, takes the approach of Option 2: the result posture of a function must be striding or grounded and the argument to a function must also be striding or grounded. To accomplish this, the parameter that can take nodes, which can at most be one parameter, will have a context posture of striding and is by itself motionless.

Approach 2: analyzing stylesheet functions from the function call

Radically different from the previous approach is to analyze the function's body only when we actually know what the context is of the argument that takes a streamed node. For this approach, we simply ignore analyzing the declaration of the function on itself.

If we take the example from Code listing: streamable my:for-each failing with argument postures climbing and crawling and call it with a striding argument, for instance my:for-each2(*/books/book), the processor, upon encountering such function call, takes the posture of the argument and sets the context posture of $node-set to this posture, in this case: striding. With this posture, the processor can now analyze the function body and return a result of that analysis, not surprisingly the same as in the previous section: a consuming sweep and a grounded result posture (because the function does not return any nodes, the result is grounded).

If user were to call the function with a crawling argument, say my:for-each2(*/books//book) (mark the extra slash), the parameter $node-set is set to a context posture of crawling and the resulting analysis of the whole function body will be roaming and free-ranging. Exactly as expected. And with a climbing argument, or even a roaming argument, the result would be the same.

Doing the same analysis for the first example, Code listing: streamable my:for-each working with any argument posture, the result would be different each time, showing the advantage of this approach:

The advantage is clear, by postponing analysis of the function body until it is called, the programmer has more flexibility in creating the function and the user will get an error if he uses the function with an invalid argument. This is also the disadvantage: without a clear rule how to call the function, the user may have trouble understanding why one argument works and the other does not. The previous table showed a function, my:for-each1, that works with any posture as argument input (except roaming, but that posture will always result in an unstreamable result, whether it is a user-defined function, a build-in function or any other construct). The following table shows the drawback of this approach, where only upon calling the function it becomes apparent that certain postures are disallowed:

As we can see, only one argument posture (bar grounded, which is always allowed), striding, is allowed with the function my:for-each2, and its sweep is consuming. This is similar to our expectations, as in the previous section, we already saw that this function only worked with a striding argument posture. But in the previous approach, for Option 2, we considered this the only allowed posture for function arguments to stylesheet functions, which made it pretty clear for end users. Here, the user does not know beforehand what the argument posture can be, in fact, he needs intricate knowledge of the function body to find out what posture is allowed.

While this approach allows more flexibility, it also introduces more room for error, at least at the static development stage. Of course, the documentation of a function could contain information of how it should be used, but who reads documentation anyway?

Another advantage, though, is the potential that many existing functions might "just work". In fact, quite some functions that can be found online are often short and meant for a certain given input. As it turns out, if you take, for instance, a look at the functions on www.xsltfunctions.com that can take nodes as their arguments, quite some of them are streamable right out of the box if we would allow this approach.

Approach 3: analyzing stylesheet functions based on static posture assessments

If we try to combine the previous two approaches into one, and try to achieve both static analysis of function bodies and clear information for the users of the functions, we achieve that by decorating the functions with an extra attribute that can take one or more postures. Let us call the attribute argument-posture and add it to xsl:param, with at most one parameter allowed to have that attribute (the challenge of multiple arguments that can take nodes is discussed in section “Multiple arguments that can take nodes”). The value for the attribute is set to be one or more of grounded climbing striding crawling roaming. The postures grounded and roaming are redundant, because the former is always allowed and results in a motionless sweep and the latter is never allowed, resulting in a free-ranging sweep.

If we take the previous example, my:for-each1 and rewrite it with this additional decorating attribute, it looks like this:

<xsl:function name="my:for-each1" as="attribute()*">
    <xsl:param name="$node-set"
        as="node()*"
        argument-posture="climbing striding crawling" />

    <xsl:for-each select="$node-set">
        <xsl:sequence select="./@name" />
    </xsl:for-each>
</xsl:function>

This tells the processor that the programmer declares the function to be streamable with each and every one of these postures. The processor can then statically assess the function body with each posture one by one and report back whether or not this assessment is correct or not. In this case, it would compile successfully, because all postures yield correct results.

Still, you might argue, the different input postures do not necessarily mean that the sweeps are all the same. True, but the sweep is something that can never be statically determined for a declaration, as it is dependent on the context of the caller. For instance, if the function is called with a motionless but striding argument, the resulting sweep is also motionless, because the xsl:for-each with a motionless argument and its body containing a motionless sequence constructor all together yield a motionless call to the function, even though it is striding. This is true, for instance, for the following call:

<xsl:template match="books/book[my:for-each1(.) = 'Swift')]">
    <h1>Books from Swift!</h1>
    <xsl:apply-templates />
</xsl:template>

This example shows the power of the current rules in the XSL Working Draft. The existing rules allow a function call inside a predicate in a pattern. Because the context item expression, (.) is motionless and takes the context posture as its result posture, which in this case is striding, the result of calling the function with this argument is also motionless and has a result posture of climbing (which follows from our table above). Finally, the result must be atomized to be able to compare it to a string. For a climbing expression that returns an attribute, atomization is allowed and motionless.

As we can see, this third approach gives us more flexibility, but the drawback is that it requires programmers to understand what a posture is. One of the design goals of the streamability rules is that they can be applied without knowing all the internals, and bringing one of those internals, the posture of a construct, to the surface, may not be desirable.

In the next sections we dive deeper in the analysis of stylesheet functions and try to come up with a set of rules that works for different inputs, not only striding, and that works also with recursion or non-final packaged functions, subjects that have not yet been touched in this section.

Direct recursion

To understand the challenges when dealing with recursive functions it is enough to look at a most trivial example, which is clearly streamable and uses infinite direct recursion:

<xsl:function name="f:recur">
    <xsl:param name="n" />
    <xsl:sequence select="f:recur($n)" />
</xsl:function>

<xsl:template match="x">
    <xsl:apply-templates select="f:recur(y)" />
</xsl:template>

This function does not have an exit-clause for the recursion and will run indefinitely, likely causing a stackoverflow error. But it is legal XSLT and it is streamable in the sense that it no movement occurs on the streamed argument.

If we analyze this function using Table III: Posture and sweep of stylesheet functions, we run into a problem:

It is not trivial to resolve this dead end situation. One way forward could be to split the function body artificially into two operands and analyze each individually: one for the part without the recursion point^[18], setting the recursive function to the empty sequence (), and one for the argument to the recursion point. This will help somewhat, but feels wrong and is hard to proof right. What would happen if a function returns streamed nodes and gets a climbing input and the output is of a different posture?

Looking back at Table III: Posture and sweep of stylesheet functions we can deduct that any function call with a climbing or crawling argument must yield a climbing or crawling result. The only argument that is allowed to return a different result posture is an input with a striding posture. This makes sense, because the natural process for streaming is to go through the input document depth-first, which is the striding posture and once you change direction upwards, you cannot go down again: it would make a construct roaming. To summarize, we can consider that:

The following table shows what this means for different argument postures of calls to a function, what the recursive argument (the one at the recursion point) can be and the result posture of the recursive call is and what the posture of the function body must be (it must be the same) and what the sweep is of the recursive call. The last column stresses the maximum sweep of the function body with the given arguments. Note that all these analyses are in the context of the initial function call, not the recursive call, which makes it possible to allow one function body to take different postures as input:

For this table to work in practice, we can allow at most one recursion point, or each recursion point must have the same posture and at most one can be consuming. Once you have found the posture and sweeps of the recursive function call, you can continue the analysis of the function body and then apply the previous Table III: Posture and sweep of stylesheet functions.

The rules in this table are laid out in such a way that it is not possible to have a climbing expression as the argument to a recursive function at a recursion point and somewhere else in the same function body a consuming construct or a non-climbing result. This is necessary, because if we would allow the combination of a climbing recursion point and a striding function body, then on either the initial call (with a climbing argument) or the recursive call (if the initial call would have been striding for instance) would call the function with an incompatible climbing posture, which would then be consumed. And a climbing posture can never be consumed. More specifically, it prevents a function like the following to be considered streamable:

<xsl:function name="f:climbstri">
    <xsl:param name="n" />
    <xsl:choose>
        <xsl:when test="f:climbstri($n/ancestor::foo)/contains(., 'bar')">
            <xsl:text>Found it</xsl:text>
        </xsl:when>
        <xsl:otherwise>
            <xsl:value-of select="$n" />
        </xsl:otherwise>
    </xsl:choose>
</xsl:function>

Glancing over the example might already give a hint as to why it cannot possibly be streamable: the xsl:value-of can consume a streamed node and that streamed node is likely to be at a climbing axis because of the climbing posture of the recursive argument. If we take the item in the table into account and consider calling this function with a striding argument, as with f:climbstr(a/b) then we find in the entry for striding and climbing that the body of the function must at most be motionless. It is consuming, because of the xsl:value-of so the analysis fails and the function is roaming and free-ranging.

If we go back to our original example (see Code listing: trivial direct recursion) and apply the rules of this table, we have one recursion point, f:recur($n), the argument is direct-transitional, that is, it is motionless and takes the posture of its caller, in this case the caller of the function. According to the table above, we can use any posture as input, which will then become the result posture, and the sweep of the function body follows as motionless and grounded. In our case, the call has a child-select expression in f:recur(y), which has posture striding and sweep consuming. The result posture and sweep of the whole template is then grounded and consuming.

Indirect recursion

With indirect recursion there are extra layers of calls before the recursion takes place, as in A calls B calls C calls A again. The question that rises is whether the rules in section “Direct recursion” also hold if a function calls itself indirectly. Indirect recursion is a type of recursion that can also be determined statically. Let us look at an example:

<xsl:function name="f:filterattr">
    <xsl:param name="n" />
    <xsl:param name="filter" />
    <xsl:sequence select="$n/@*[name() = $filter]" />
    <!-- indirect recursion -->
    <xsl:sequence select="f:take-ancestor($n, $filter)" />
</xsl:function>

<xsl:function name="f:take-ancestor">
    <xsl:param name="n" />
    <xsl:param name="filter" />
    <xsl:sequence select="
        if($n) 
        (: indirect recursion :)
        then f:filterattr($n/ancestor::element()[1], $filter) 
        else ()" />
</xsl:function>

The example is a very verbose and clumsy way of getting all attributes of all ancestor-or-self nodes that have a certain name. For instance, with the following input and stylesheet, the output will be 3.14 1.64:

<foo version="1.64" name="john">
    <zed>
        <bar version="3.14" id="1234">
    </zed>
</foo>

<xsl:mode on-no-match="shallow-skip" />

<xsl:template match="bar">
    <xsl:value-of select="f:filterattr(., 'version')" />
</xsl:template>

But whether it is clumsy or not is not the matter. It serves as a basic example of indirect recursion and the function is clearly streamable because it only traverses the ancestor and attribute axes, which are motionless. However, the question is, of course, whether this example is streamable by following the rules from Table IV: Posture and sweep of recursive stylesheet function calls.

If we try that a first time, we quickly find that it is not immediately obvious how to apply it, because the functions above are not directly recursive. Recall that we said in section “Direct recursion” we wrote we can allow at most one recursion point, or each recursion point must have the same posture and at most one can be consuming . There are two recursion points here, the one inside f:filterattr that calls f:take-ancestor and the one inside f:take-ancestor that calls f:filterattr. The posture of the first one takes the input posture of the argument, it is Direct-transitional, the second one traverses the ancestor axis, which gives it a climbing posture. Finally, the argument inside the template example in Code listing: indirect recursive function call example has itself a posture of striding, because the context item expression takes the context posture which in the case of xsl:template is striding.

In short, if we start at the template, we start with posture striding, then striding again (because it is direct-transitional), then climbing and on the next recursive iteration this repeats, but now from climbing as input to f:filter-attr, then climbing again (because direct-transitional takes over the posture of the argument) and so it continues climbing until all recursive iterations have finished.

This breaks the rule we set to ourselves: the posture changed from striding to climbing. Yet, we also established that the example functions were streamable. The conflict arises from the argument $n being direct-transitional, which works like a cameleon and changes the posture along the way. One resolution to this specific situation is to allow direct-transitional, provided the rest of the body of the function is motionless, in which case it does no harm. Another, perhaps easier solution is to force the same posture in, same posture out rule and rewrite the argument to this function as follows:

<xsl:mode on-no-match="shallow-skip" />

<xsl:template match="bar">
    <xsl:value-of select="f:filterattr(./ancestor-or-self::*[1], 'version')" />
</xsl:template>

The change to using the ancestor-or-self axis also changes the initial posture to climbing, which in turn changes the posture of $n to be climbing as well, making all postures in all recursion points climbing.

While this relatively trivial example seemed to show an edge-case because it used a recursive argument posture of direct-transitional, it taught us two things: one, even a trivial example can quickly appear hard once we try to apply streamability rules on them and two, to keep things simple, it is best to stick a set of ground rules, even though that potentially means that we slightly limit certain use-cases.

In practice, indirect recursion is found pretty rarely in XSLT programming, even though XSLT is itself a functional language, it is much more common to use direct recursion. But if a scenario requires indirect recursion, it is possible, even with streaming.

Indeterminate recursion

Another challenge comes from indeterminate recursion as in the following example:

<xsl:function name="f:indeter">
    <xsl:param name="n" />
    <xsl:apply-templates select="$n" mode="streamable" />
</xsl:function>

<xsl:template match="*" mode="streamable">
    <xsl:sequence select="f:indeter(.)" />
</xsl:template>

In this situation, the analysis of the function declaration and the template declaration can be done independently, without ever finding the recursion point. However, when this code is run, the recursion kicks in (assuming the argument is an element). There is, however, one big advantage to this type of recursion: the rules on templates define that the result of a template declaration must be grounded^[20]. Therefore, by definition, the result of any xsl:apply-templates is also grounded, which gives the function body above a grounded posture as well. In turn, the call to f:indeter results in a grounded posture, which concludes the circle. In addition, any select-expression in xsl:apply-templates must be atomizable, which in streamability terms means that it cannot be climbing or crawling^[21]. This leads us to a temporary conclusion: if the arguments to a function are striding they can be used in indeterminate recursive functions. If the arguments are not striding, the analysis fails and makes the call on the function roaming and free-ranging.

Following Table III: Posture and sweep of stylesheet functions and taking the same approach that the body of the function should be analyzed during the call to the function, we can conclude that it is impossible for a function body to apply templates on something else then a striding posture. The one exception that is allowed in the General Streamability Rules^[22]is for a climbing posture of childless nodes, which only applies to the attribute axis. This means that we can consider the following example streamable as well, even though we pass a climbing, or even a crawling expression to the function:

<xsl:function name="f:apply-attribs">
    <xsl:param name="n" />
    <xsl:apply-templates select="$n/@*" />
</xsl:function>

Whether or not that function will be called indeterminate-recursively or not is irrelevant, because on the second iteration, the selection will be empty, because attribute nodes do not have children.

In short: indeterminate recursion does not have influence on the streamability analysis, nor does it break it. The existing rules suffice.

Dynamic recursion

Dynamic recursion looks a bit like indeterminate recursion in the sense that whether or not recursion takes place cannot be determined statically. In XPath 3.0, it is possible to bind a variable to a function^[23], this is commonly referred to as higher order functions. The concept is not new, already in 2001, Dimitre Novatchev showed in his paper Novatchev 2001 that writing higher order functions is possible in XSLT 1.0 by means of what he calls template references^[24], a concept also applied to the functional coding patterns in Mangano 2005, which was further popularized as the Novatchev technique in Kay 2008. It took until XSLT and XPath 3.0 that function items became first-class citizens, see my own paper Braaksma 2013 for an extended coverage of that subject for XSLT and Grust 2013 for a coverage for XQuery and databases.

For the rest of this section, we will assume you have a basic understanding of higher order functions in XSLT and XPath. The closure of higher order functions cannot contain the context item, so for our analysis we should only worry about arguments that can be streamed nodes, just like with regular functions.

The nature of a dynamic function call is that the function it refers to is only known at runtime, when the variable is bound to a function item. As a result, there is not much we can say of the posture and sweep of the function it refers to until it is actually invoked. Following the rules on streamability, the result of binding a variable to a function item is always grounded. This makes sense, because at the moment of binding, a function item is assigned to a variable and no streamed nodes are possibly involved in the result.

Once a function item is evaluated, its arguments are known. Provided that the arguments themselves are not roaming and free-ranging, the analysis will thenceforth look at the bound function. If this function is streamable, we can do the analysis from the previous sections as if it was a direct function call. The biggest difference lies in the fact that the analysis is done during execution. This means that an error for whether a call is not streamable will be a dynamic error.

This is no different for dynamic recursion. If dynamic evaluation leads to a recursive call, the posture of the argument, the recursive call and the function body must be matched to Table IV: Posture and sweep of recursive stylesheet function calls. If the result is roaming and free-ranging, the recursive call is not guaranteed streamable.

While it is theoretically possible to allow such dynamic streamability rules, the rules in the specification are meant to guarantee streamability statically. As a result, any potential dynamic streamability is prohibited. Processors may allow dynamic streamability as a vendor extension, but the specification will consider passing a node to a dynamic function call not guaranteed streamable, dynamic recursion, as suggested in this section, is therefor not possible with the current set of rules on static guaranteed streamability.

Analyzable and non-analyzable functions

Analyzable stylesheet functions are functions that can be analyzed by themselves, as we saw in . Non-analyzable stylesheet functions are those that can only be analyzed from the function call, because the body of the function on itself cannot be analyzed without knowing what the argument is. Most of the previous sections was about non-analyzable function calls.

Spec-wise, the term non-analyzable refers to the set of functions that cannot be analyzed statically and are given very conservative assumptions on streamability. This is true for recursive stylesheet functions and non-final streamable functions (see section “Non-final streamable functions in packages”). The term non-analyzable does not necessarily mean that the function is not analyzable, however, the general rule is that it requires a call, or knowledge of the context of a call to the function to find out whether or not the function is streamable. We have seen in the previous sections that it is possible to allow quite a variety of postures, even for non-analyzable functions, but in the specification such functions are limited to a posture of striding and are always considered consuming even if in fact they are not.

Inline functions and streamability

Inline functions are a new XPath 3.0 capability^[28] that allows you to write an anonymous function inside an XPath expression. The definition of inline function expressions prohibits referencing the context item, which makes it not directly possible to refer to the context. However, the closure of an inline function contains all local variable bindings, which makes it possible to refer to a variable outside of the inline function, which itself could be bound to a streamed node. The streamability rules for xsl:variable and xsl:param prohibit referencing a streamed node, but one exception is inside a streamable stylesheet function, where it is possible to have a parameter bound to a streamed node.

There are two solutions possible. One is to come up with complex rules for inline functions referencing the streamed parameter, the other is to simply prohibit using a streamed parameter inside an inline function body. This in itself would not be consistent with the definition in XPath, which states that all local variable bindings are available in the dynamic context of the inline function, which leads us to a third option: simply disallow inline function expressions within the body of a streamable stylesheet function.

This third option would be in line with the current streamability rules for inline function declarations^[29], which states that they are, by definition, grounded and motionless, simply because it is not possible to pass a streamed node into the closure of the inline function body.

Partial function application and streamability

Partial function application is also a new XPath 3.0 capability by writing down a question mark as a placeholder for an argument^[30], and apply the other arguments already. The result is a function item with less arguments than the original and some arguments already filled in. An example is the expression index-of(?, ?, "http://my-collation"), which returns a function item that presets the collation argument to http://my-collation, resulting in a two-argument function that always uses the same collation.

The current rules are under the rules on function calls^[31] state that, unless the function is focus-dependent, that the general streamability rules apply, which means that it is treated as a normal function call, but the placeholder arguments are ignored.

If we take into consideration that binding a streamed node to a variable and passing it around is prohibited, a similar rule should be applied to partial function application: if the function is a streamable stylesheet function, the argument that can take a streamed node, must be the placeholder, or a grounded node must be supplied, otherwise it would become a roaming and free-ranging expression.

In other words, partial function application works with user-defined streamable stylesheet functions, as long as you do not try to bind a streaming node from the current context to it. You should do that at a later stage, when you actually call the function.

Named function references and streamability

Named function references are another XPath 3.0 feature^[32]: you can create a function item of an existing function by using the syntax FunctionName#ArgCount, where ArgCount is a literal giving the arity of the function. For instance, count#0 will give a reference to the zero-argument function of count and my:filter#3 will give a reference to a three-argument function my:filter.

The function item returned by such an expression can be called as a normal function by applying parentheses and arguments, which in turn will call the function you referred to to begin with. In practice, this syntax is useful for binding variables to existing named functions.

Creating a named function reference is an atomic action and does not involve references to nodes. As a result, a named function reference itself is always grounded. There is one exception, if you try to create a reference to a function that is focus-dependent. In such cases, just like in previous rules, the result is roaming and free-ranging. This is in fact the current rule for streamability of named function references in the specification^[33].

Since stylesheet functions by definition cannot be focus-dependent, this exception does not apply to named function references that refer to a (streamable) stylesheet function.

Dynamic function calls and streamability

A dynamic function call, also a new XPath 3.0 feature^[34], is a call to a function item that is bound to a variable. Suppose you have <xsl:variable name="fref" select=" 'name#1' " />, which binds the one-argument version of the name-function to $fref, then you can call that function by adding parentheses and arguments, the same way you would have done if the variable were the actual function: $fref(child::*[1]).

Since it is not possible to know at runtime what function the variable is bound to, analysis can only take place once the function is actually called. The current rules^[35] state that all arguments have operand usage navigation, which means that you can only call a dynamic function when you actually create a grounded copy of a streamed node. In case you wanted to apply it to a streamed node you are out of luck.

The rules make an exception in case the signature of the function item is known, in which case type-determined usage, as in part explained in section “An improvement: type-determined posture”, can be used. That means that, if an argument is declared as a non-node type, the usage typically becomes absorption.

The streamable attribute on xsl:function

In none of the previous sections in this paper have I mentioned the streamable attribute on an xsl:function declaration. Since most of the paper discussed streamability of a stylesheet function in the context of the function call, whether or not a function is streamable then depends on its implementation and there is no need for the processor to know beforehand what functions to analyze and what not.

The streamability rules in the specification are made such that the processor must statically determine whether or not a function declaration is streamable or not. Since it is likely that any given stylesheet will have both streamable and non-streamable stylesheet functions, it is necessary to tell the processor which are and which are not streamable. For that, the xsl:function declaration gets a new attribute, similar to the attribute of xsl:accumulator and xsl:mode, which determines whether or not a function should be analyzed for streamability.

The attribute takes a value of yes or no. If the value is yes, then the function must be guaranteed streamable and the function can be called with a streamable node as an argument.

I think that such an attribute is not necessary if we take the approach in this paper and analyze the entire function only upon the actual function call. If that function call is inside a streamable context and a streamable node is passed as an argument, the body of the function is analyzed with the context posture of the streamable argument set as the posture of the streamable parameter reference.