In this specification the phrases must, must not, should, should not, may, required, and recommended, when used in normative text and rendered in small capitals, are to be interpreted as described in .

Where the phrase must, must not, or required relates to the behavior of the XSLT processor, then an implementation is not conformant unless it behaves as specified, subject to the more detailed rules in .

Where the phrase must, must not, or required relates to a stylesheet then the processor must enforce this constraint on stylesheets by raising an error if the constraint is not satisfied.

Where the phrase should, should not, or recommended relates to a stylesheet then a processor may produce warning messages if the constraint is not satisfied, but must not treat this as an error.

In this specification, the term implementation-defined refers to a feature where the implementation is allowed some flexibility, and where the choices made by the implementation must be described in documentation that accompanies any conformance claim.

The term implementation-dependent refers to a feature where the behavior may vary from one implementation to another, and where the vendor is not expected to provide a full specification of the behavior. (This might apply, for example, to limits on the size of source documents that can be transformed.)

In all cases where this specification leaves the behavior implementation-defined or implementation-dependent, the implementation has the option of providing mechanisms that allow the user to influence the behavior.

A paragraph labeled as a Note or described as an example is non-normative.

The term streaming refers to a manner of processing in which XML documents (such as source and result documents) are not represented by a complete tree of nodes occupying memory proportional to document size, but instead are processed “on the fly” as a sequence of events, similar in concept to the stream of events notified by an XML parser to represent markup in lexical XML.

A streamed document is a source tree that is processed using streaming, that is, without constructing a complete tree of nodes in memory.

A streamed node is a node in a streamed document.

Many processors implementing earlier versions of this specification adopted an architecture that allowed streaming of the result tree directly to a serializer, without first materializing the complete result tree in memory. Streaming of the source tree, however, has proved to be more difficult without subsetting the language. This has created a situation where documents exceeding the capacity of virtual memory could not be transformed. XSLT 3.0 therefore introduced facilities allowing stylesheets to be written in a way that makes streaming of source documents possible, without excessive reliance on processor-specific optimization techniques.

Streaming achieves two important objectives: it allows large documents to be transformed without requiring correspondingly large amounts of memory; and it allows the processor to start producing output before it has finished receiving its input, thus reducing latency.

This specification does not attempt to legislate precisely which implementation techniques fall under the definition of streaming, and which do not. A number of techniques are available that reduce memory requirements, while still requiring a degree of buffering, or allocation of memory to partial results. A stylesheet that requests streaming of a source document is indicating that the processor should avoid assuming that the entire source document will fit in memory; in return, the stylesheet must be written in a way that makes streaming possible. This specification does not attempt to describe the algorithms that the processor should actually use, or to impose quantitative constraints on the resources that these algorithms should consume.

Nothing in the XSLT specification prevents a processor using streaming whenever it sees an opportunity to do so. However, experience has shown that in order to achieve streaming, it is often necessary to write stylesheet code in such a way as to make this possible. Therefore, XSLT provides explicit constructs allowing the stylesheet author to request streaming, and defines explicit static constraints on the structure of the code which are designed to make streaming possible.

A processor that claims conformance with the streaming option offers a guarantee that when streaming is requested for a source document, and when the stylesheet conforms to the rules that make the processing , then an algorithm will be adopted in which memory consumption is either completely independent of document size, or increases only very slowly as document size increases, allowing documents to be processed that are orders-of-magnitude larger than the physical memory available. A processor that does not claim conformance with the streaming option must still process a stylesheet and deliver the correct results, but is not required to use streaming algorithms, and may therefore fail with out-of-memory errors when presented with large source documents.

Apart from the fact that there are constructs to request streaming, and rules that must be followed to guarantee that streaming is possible, the language has been designed so there are as few differences as possible between streaming and non-streaming evaluation. The semantics of the language continue to be expressed in terms of the XDM data model, which is substantively unchanged; but readers must take care to observe that when terms like “node” and “axis” are used, the concepts are completely abstract and may have no direct representation in the run-time execution environment.

Streamed processing of a document can be initiated in one of three ways:

The rules for streamability, which are defined in detail in , impose two main constraints:

The second restriction, that only one visit to the children is allowed, means that XSLT code that was not designed with streaming in mind will often need to be rewritten to make it streamable. In many cases it is possible to do this using a technique sometimes called windowing or burst-mode streaming (note this is not quite the same meaning as windowing in XQuery 3.0). Many XML documents consist of a large number of elements, each of manageable size, representing transactions or business objects where each such element can be processed independently: in such cases, an effective design pattern is to write a streaming transformation that takes a snapshot of each element in turn, processing the snapshot using the full power of the XSLT language. Each snapshot is a tree built in memory and is therefore fully navigable. For details see the snapshot and copy-of functions.

The new facility of accumulators allows applications complete control over how much information is retained (and by implication, how much memory is required) in the course of a pass over a . An accumulator computes a value for every node in a streamed document: or more accurately, two values, one for the first visit to a node (before visiting its descendants), and a second value for the second visit to the node (after visiting the descendants). The computation is structured in such a way that the value for a given node can depend only on the value for the previous node in document order together with the data available when positioned at the current node (for example, the attribute values). Based on the well-established fold operation of functional programming languages, accumulators provide the convenience and economy of mutable variables while remaining within the constraints of a purely declarative processing model.

When streaming is initiated, for example using the xsl:source-document instruction, it is necessary to declare which accumulators are applicable to the streamed document.

Streaming applications often fall into one of the following categories:

There are important classes of application in which streaming is possible only if multiple streams can be processed in parallel. This specification therefore provides facilities:

These facilities have been designed in such a way that they can readily be implemented using streaming, that is, without materializing the input or output sequences in memory.

Streaming can be combined with schema-aware processing: that is, the streamed input to a transformation can be subjected to on-the-fly validation, a process which typically accepts an input stream from the XML parser and delivers an output stream (of type-annotated nodes) to the transformation processor. The XSD specification is designed so that validation is, with one or two exceptions, a streamable process. The exceptions include:

Applications that need to run in finite memory may therefore need to avoid these XSD features, or to use them with care.

XSD is designed so that the intended type of an element (the “governing type”) can be determined as soon as the start tag of the element is encountered: the process of validation checks whether the content of the element actually conforms to this type, and by the time the end tag is encountered, the process will have established either that the element is valid against the governing type, or that it is invalid.

By default, dynamic errors occurring during streamed processing are fatal: they typically cause the transformation to fail immediately. XSLT 3.0 introduced the ability to catch dynamic errors and recover from them. Schema invalidity, however, is treated as a dynamic error of the instruction that processes the entire input stream, so after a validation failure, no further processing of that input stream is possible.

In consequence, a streamed validator that is running in tandem with a streamed transformation can present the transformer with element nodes that carry a provisional type annotation representing the type that the element will have if it turns out to be valid. As soon as a node is encountered that violates this assumption, the validator should stop the flow of data to the transformer, so that the transformer never sees invalid data. This allows the stylesheet code to be compiled with the assumption of type-safety: at run-time, all nodes seen by the transformation will conform to their XSLT-declared types (for example, a type declared implicitly using match="schema-element(invoice)" on an xsl:template element).

A streamed transformation that only accesses part of the input document (for example, a header at the start of a document) is not required to continue reading once the data it needs has been read. This means that XML well-formedness or validity errors occurring in the unread part of the input stream may go undetected.

With a streamable processor, the > can consist of streamed nodes, but the is always , because it is available to all global variables and there is no control over the sequence of processing.

If the initial mode is , then a streaming processor should allow some or all of the items in the to be nodes supplied in streamable form, and any nodes that are supplied in this form must then be processed using streaming.

Since the cannot be a streamed node, in cases where the transformation is to proceed by applying streamable templates to a streamed input document, the must either be absent, or must be something that differs from the .

The facilities in this specification designed to enable large data sets to be processed in a streaming manner are oriented almost entirely to XML data. This does not mean that there is never a requirement to stream non-XML data, or that the Working Group has ignored this requirement; rather, the Working Group has concluded that for the most part, streaming of non-XML data can be achieved by implementations without the need for specific language features in XSLT.

To make streamed processing of unparsed text files easier, the function unparsed-text-lines has been introduced. This is not only more convenient for stylesheet authors than reading the entire input using the unparsed-text function and then tokenizing the result, it is also easier for implementations to optimize, allowing each line of text to be discarded from memory after it has been processed.

For all functions that access external data, including document, doc, collection, unparsed-text, unparsed-text-lines, and json-doc, the requirements on determinism can now be relaxed using configuration options. This is significant because it means that when a transformation reads the same external resource more than once, it becomes legitimate for the contents of the resource to be different on different invocations, and this eliminates the need for the processor to cache the contents of the resource in memory.

In the XDM data model, every value is a sequence, and (as with most functional programming languages), processing of sequences of items is pervasive throughout the XSLT and XPath languages and their function library. Good performance of a functional programming language often depends on sequence-based operations being pipelined, and being evaluated in a lazy fashion (that is, many operations process items in a sequence one at a time, in order; and many operations can deliver a result without processing the entire sequence). The semantics of XSLT and XPath permit pipelined and lazy evaluation (for example, the error handling semantics are carefully written to ensure this), but they do not require it: the details are left to implementations. Pipelined processing of a sequence is not the same thing as streamed processing of a tree, and where the XSLT specification talks of operations being “guaranteed streamable”, this is always referring to processing of trees, not of sequences.

The facilities for streaming of XML trees include operations such as copy-of and snapshot which are able to take a sequence of streamed nodes as input, and produce a sequence of in-memory (unstreamed) nodes as output. It is also possible to generate a sequence of strings or other atomic items through the process of atomization. The actual memory usage of a streamed XSLT application may depend significantly on whether the processing of the resulting sequence of in-memory nodes or atomic items is pipelined or not. The specification, however, has nothing to say on this matter: it is considered an area where implementers can exercise their discretion and ingenuity.

Streaming of JSON input receives little attention in this specification. One can envisage an implementation of the json-to-xml function in which the XML delivered by the function consists of streamed nodes; but the Working Group has not researched the feasibility of such an implementation in any detail.

Certain constructs allow a stylesheet author to declare that a construct is streamable. Specifically:

The above constructs (template rules belonging to a mode declared with streamable="yes"; and xsl:source-document, xsl:attribute-set, xsl:function, xsl:merge-source, and xsl:accumulator elements specifying streamable="yes") are said to be declared-streamable.

In each case the construct in question is said to be guaranteed-streamable if it satisfies two conditions:

A guaranteed-streamable construct is a construct that is declared to be streamable and that follows the particular rules for that construct to make streaming possible, as defined by the analysis in this specification.

For a streaming processor, that is, a processor that claims conformance with the :

It is a if a package contains a construct that is declared to be streamable but which is not . A processor is not required to report this error if it is capable of processing the stylesheet using streaming.

For a non-streaming processor, the processor must evaluate the construct delivering the same results as if execution used streaming, but with no constraints on the evaluation strategy. (Processing may, of course, fail due to insufficient memory being available, or for other reasons.) A non-streaming processor is not required to assess whether constructs are , or to apply restrictions such as the rules for where calls on the functions accumulator-before and accumulator-after may appear. However, a non-streaming processor must enforce the constraint implied by a use-accumulators attribute restricting which accumulators can be used with a particular document.

For every construct kind, there is a set of zero or more operand roles. For example, an AdditiveExpr has two operand roles, referred to as the left-hand operand and the right-hand operand, while an IfExpr has three, referred to as the condition, the then-clause, and the else-clause. A function call with three arguments has three operand roles, called the first, second, and third arguments. The names of the operand roles for each construct kind are not formally listed, but should be clear from the context.

In an actual instance of a construct, there will be a number of operands. Each operand is itself a ; the construct tree can be defined as the transitive relation between constructs and their operands. Each operand is associated with exactly one of the operand roles for the construct type. There may be operand roles where the operand is optional (for example, the separator attribute of the xsl:value-of instruction), and there may be operand roles that can be occupied by multiple operands (for example, the xsl:when/@test condition in xsl:choose, or the arguments of the concat function).

Operand roles have a number of properties used in the analysis:

An gives information about the operands of a particular kind of construct. The two important properties of an operand role are the required type and the operand usage.

The usage of an operand role is relevant only when the value of an supplied in that role is a node, or a sequence that contains nodes. It is one of the following:

The concept of operand usage is not used for all constructs (for example, it is not used in the analysis of path expressions). Where it is used, the assignment of operand usages to each operand role of a construct is defined in the relevant subsection of .

The process of determining whether a construct is streamable reduces to determining properties of the constructs in the construct tree. The properties in question (which are described in greater detail in subsequent sections) are:

The values of these properties for a top-level construct such as the body of a template rule determine whether the construct is streamable.

The values of these properties are not independent. For example, if the static type is atomic, then the posture will always be grounded; if the sweep is free-ranging, then the posture will always be roaming.

The and of a , as defined above, are calculated in relation to a particular streamed input document. If there is more than one streamed input document, then a construct that is motionless with respect to one streamed input might be consuming with respect to another. In practice, though, the streamability analysis is only ever concerned with one particular streamed input at a time; constructs are analyzed in relation to the innermost containing xsl:template, xsl:source-document, xsl:accumulator, or xsl:merge-source element, and this container implicitly defines the streamed input document that is relevant. The streamed input document affecting a construct is always the document that contains the context item for evaluation of that construct.

The static type of a construct is such that all values produced by evaluating the construct will conform to that type. The static type of a construct comprises a and a cardinality. A cardinality is a range of integers (from min to max).

A U-type is a set of fundamental item types.

There are 29 fundamental item types: the 7 node kinds defined in (element, attribute, etc.), the 19 primitive atomic types defined in , plus the types fn(*), xs:untypedAtomic, and JNode. The fundamental item types are disjoint, and every item is an instance of exactly one of them.

More specifically, the fundamental item types are:

TODO: extend the analysis to include JNodes.

A value V (in general, a sequence) is an instance of a U if every item in V is an instance of one of the fundamental item types in U. For example, the sequence (23, "Paris") is an instance of the U-type U{xs:string, xs:decimal, xs:date} because both items in the sequence belong to item types in this U-type.

A is represented in this specification using the notation U{t1, t2, t3, ...} where t1, t2, t3, ... are the names of the fundamental item types making up the U-type. The item types are represented using the syntax of the ItemType production in XPath, for example comment() or xs:date.

The smallest U-type is denoted U{}. This is not an empty type; like every other U-type, it has the empty sequence () as an instance. For convenience, the universal U-type is represented as U{*}; the U-type corresponding to the set of 7 node kinds is written U{N}, and the U-type corresponding to all atomic items (that is, the 19 primitive atomic types plus xs:untypedAtomic) is written U{A}.

Because a is a set, the operations of union, intersection, and difference are defined over U-types, and the result is always a U-type. If one U-type U is a subset of another U-type V, then U is said to be a subtype of V, and V is said to be a supertype of U.

In some cases the inference of a depends on the declared types of variables or functions. Since declared types use the syntax, there is therefore a mapping defined from SequenceTypes to U-types. The mapping is as follows:

For every expression, it is possible to establish by static analysis, information about the item type of the context item for evaluation of that expression. This is called the context item type of the expression.

The of an expression is a .

The semantics of every construct, defined in this specification or in the XPath specification, describe how the for evaluating each of the construct is determined. In most cases the focus is the same as that of the parent construct. In some cases the focus is determined by evaluating some other expression, for example in the expressions A/B, A!B, A[B], A?[B], or A -> B the focus for evaluating B is A. More generally:

The of a construct C is the first of the following that applies:

The match type of a is the most specific that is known to match all items that the pattern can match. The match type of a pattern is the inferred of the pattern’s equivalent expression, determined according to the rules in . For example, the match type of the pattern para[1] is U{element()}, while that of the pattern @code[.='x'] is U{attribute()}

The effect of on streamability analysis is illustrated in the following examples:

The posture of a construct indicates the relationship of the nodes selected by the to a streamed input document. The value is one of the following:

The of a construct is determined in one of several ways:

The characterization of an expression as striding, crawling, climbing, or roaming applies only to the streamed nodes in the result of the expression. The result of the expression may also contain non-streamed (grounded) nodes or atomic items. For example if /x/y is a striding expression, then (/x/y | $doc//x) is also striding, given that $doc contains non-streamed nodes. The assertion that the nodes in the result of a striding expression are in document order and are peers thus applies only to the subset of the nodes that are streamed.

Every construct has a sweep, which is a measure of the extent to which the current position in the input stream moves during the evaluation of the expression. The sweep is one of: , , or . This list of values is ordered: a expression has wider sweep than a expression, which has wider sweep than a expression.

A motionless is any construct deemed motionless by the rules for that construct (typically given in ). Informally, a motionless construct is one that can be evaluated without changing the current position in the input stream.

A consuming construct is any deemed consuming by the rules for that construct (typically given in ). Informally, a consuming construct is one whose evaluation requires repositioning of the input stream from the start of the current node to the end of the current node.

A free-ranging construct is any deemed free-ranging by the rules for that construct (typically given in ). Informally, a free-ranging construct is one whose evaluation may require access to information that is not available from the subtree rooted at the current node, together with information about ancestors of the current node and their attributes.

The table below shows some examples of expressions having different combinations of and .

Many constructs share the same streamability rules. These rules, referred to as the general streamability rules, are defined here.

Examples of constructs that use these rules are: an arithmetic expression, an , a , the xsl:text and xsl:value-of instructions, and a call to the doc function.

The rules determine both the and sweep of a construct. To determine the posture and sweep of a construct C, assuming these general rules are applicable to that kind of construct:

The xsl:source-document instruction is if both the following conditions are satisfied:

The xsl:source-document instruction can be used to initiate processing of a document using streaming with a variety of coding styles, illustrated in the examples below.

The following non-normative algorithm explains one possible strategy for streamed evaluation of a containing xsl:on-empty and/or xsl:on-non-empty instructions.

The algorithm makes use of the following mutable variables:

The algorithm is as follows:

Under specific conditions, described in this section, a stylesheet function can be used to process nodes from a streamed input document.

Stylesheet functions belong to one of a number of streamability categories: the choice of category characterizes the way in which the function handles streamed input.

The category to which a function belongs is declared in the streamability attribute of the xsl:function declaration, and defaults to unclassified.

The streamability categories defined in this specification are: unclassified, absorbing, inspection, filter, shallow-descent, deep-descent, and ascent. It is also possible to specify the streamability category as a QName in an namespace, in which case the streamability rules are ; a processor that does not recognize a category defined in this way must analyze the function as if streamability="unclassified" were specified.

A stylesheet function is if the xsl:function declaration has a streamability attribute with a value other than unclassified.

The only category permitted for a zero-arity function (one with no arguments) is unclassified. All function calls to zero-arity stylesheet functions are and .

In general (subject to more detailed rules below), a node belonging to a can be present within the value of an argument of a call on a only if one of the following conditions is true:

The first parameter of a is referred to as a streaming parameter.

The choice of category places constraints on the function body, and also on calls to the function. These constraints are defined below, separately for each category. A function is only if the constraints are satisfied, and a static function call is guaranteed-streamable only if the function is guaranteed-streamable and the function call itself satisfies the constraints for the chosen category.

Dynamic function calls are only in trivial cases, for example where the function signature indicates that an argument is required to be a text node or an attribute node. For details, see .

The constraints on the function body are expressed in terms of the and of the function result. The and of the function result are the of the contained within the xsl:function element, given the declared return type of the function, which defaults to item()*.

If the function is but does not satisfy the constraints that make it , the consequences are explained in .

If a stylesheet function is overridden in another package (using xsl:override), then the overriding stylesheet function must belong to the same as the function that it overrides. This ensures that overriding a function cannot affect the streamability of calls to that function.

The rules for each are given in the following sections.

The of an is always (its result can never return streamed nodes).

The of an is if all the following conditions hold:

Maps have many uses, but their introduction to XSLT 3.0 was strongly motivated by streaming use cases. In essence, when a source document is processed in streaming mode, data that is encountered in the course of processing may need to be retained in variables for subsequent use, because the nodes cannot be revisited. This creates a need for a flexible data structure to accommodate such temporary data, and maps were designed to fulfil this need.

The entries in a map are not allowed to contain references to streamed nodes. This is achieved by ensuring that for all constructs that supply content to be included in a map (for example the third argument of map:put, and the select attribute of xsl:map-entry), the relevant operand is defined to have operand usage . Because maps cannot contain references to streamed nodes, they are effectively , and can therefore be used freely in contexts (such as parameters to functions or templates) where only grounded operands are permitted.

The xsl:map instruction, and the XPath MapConstructor construct, are exceptions to the general rule that during streaming, only one downward selection (one consuming subexpression) is permitted. They share this characteristic with xsl:fork. As with xsl:fork, a streaming processor is expected to be able to construct the map during a single pass of the streamed input document, which may require multiple expressions to be evaluated in parallel.

In the case of the xsl:map instruction, this exemption applies only in the case where the instruction consists exclusively of xsl:map-entry (and xsl:fallback) children, and not in more complex cases where the map entries are constructed dynamically (for example using a control flow implemented using xsl:choose, xsl:for-each, or xsl:call-template). Such cases may, of course, be streamable if they only have a single consuming subexpression.

For example, the following XPath expression is streamable, despite making two downward selections:

Analysis:

The streamability of the xsl:record instruction is determined by analysing the streamability of the equivalent xsl:map instruction as described in the definition of xsl:record above.

See also: , , ,

Keys are not applicable to streamed documents.

This is ensured by the rules for the streamability of the key function (see ). These rules make the of the third argument , which has the consequence that when the key function is applied to a streamed input document, the call is and , which effectively makes the containing construct non-streamable.

A construct is grounded if the items it delivers do not include nodes from a streamed document; it is consuming if evaluation of the construct reads nodes from a streamed input in a way that requires advancing the current position in the input.

Grounded consuming constructs play an important role in streaming, and this section discusses some of their characteristics.

Examples of grounded consuming constructs (assuming the context item is a streamed node) include:

XSLT 3.0 provides the two functions copy-of and snapshot with the explicit purpose of creating a sequence of grounded nodes, that can be processed one-by-one without the usual restrictions that apply to streamed processing, such as the rule permitting at most one downward selection. The processing style that exploits these functions is often called “windowed streaming”.

In general the result of a grounded consuming construct is a sequence. Depending on how this sequence is used, it may or may not be necessary for the processor to allocate sufficient memory to hold the entire sequence. The streamability rules in this specification place few constraints on how a grounded sequence is used. This is deliberate, because it gives users control: by creating a grounded sequence (for example, by use of the copy-of function) stylesheet authors create the possibility to process data in arbitrary ways (for example, by sorting the sequence), and accept the possibility that this may consume memory.

Pipelined evaluation of a sequence is analogous to streamed processing of a source document. Pipelined evaluation occurs when the items in a sequence can be processed one-by-one, without materializing the entire sequence in memory. Pipelining is a common optimization technique in all functional programming languages. Operations for which pipelined evaluation is commonly performed include filtering ($transactions[@value gt 1000]), mapping ($transactions!(@value - @processing-fee)), and aggregation (sum($transactions)). Operations that cannot be pipelined (because, for example, the first item in the result sequence cannot be computed without knowing the last item in the input sequence) include those that change the order of items (reverse(), sort()). Other operations such as distinct-values() allow the input to be processed one item at a time, but require memory that potentially increases as the sequence length increases. Saving a grounded sequence in a variable is also likely in many cases to require allocation of memory to hold the entire sequence.

When the input to an operation is a grounded consuming sequence (more accurately, a sequence resulting from the evaluation of a grounded consuming construct), this specification does not attempt to dictate whether the operation is pipelined or not. The goal of interoperable streaming in finite memory can therefore only be achieved if stylesheet authors take care to avoid constructing grounded sequences that occupy large amounts of memory. In practice, however, users can expect that many grounded consuming constructs will be pipelined where the semantics permit this.

The use of the last function requires particular care because of its effect on pipelining. The streamability rules prevent the use of last() in conjunction with an expression that returns streamed nodes (because it would require look-ahead in the stream), but there is no similar constraint for grounded sequences. So for example it is not permitted (in a context that requires streaming) to write

but it is quite permissible to write

because the call on copy-of makes the sequence grounded. This construct cannot be pipelined because computing the first item in the result sequence depends on knowing the length of the input sequence; in consequence, a processor might be obliged to buffer all the transactions (or their copies) in memory. In this simple example the impact of the call on last is easily detected both by the human reader and by the XSLT processor, but there are other cases where the effect is less obvious. For example if the stylesheet executes the instruction

then the presence of a call on last in one of the template rules that gets invoked might not be easily spotted; yet the effect is exactly the same in preventing the result being computed by processing input items strictly one at a time. Avoiding such effects is entirely the responsibility of the stylesheet author.

By contrast, there is no intrinsic reason why use of the position should prevent pipelined processing: all it requires is for the processor to count how many items have been processed so far. Processors may also be able to handle the construct position() = last() without storing the entire sequence in memory; rather than actually evaluating the numeric values of position() and last(), this can be done by testing whether the context item is the last item in the sequence, which only requires a one-item lookahead.

The and sweep of a are determined by the .

The operand roles and their usages are:

This section describes how instructions are classified with respect to their streamability. The criteria are given first for literal result elements and extension instructions, then for each XSLT instruction, listed alphabetically.

A value template (that is, an or ) is a whose operands are the expressions contained within curly brackets. The required type for this operand role is xs:string and the usage is .

The and of a value template are determined using the general rules in .

If there are no expressions contained within curly brackets, the value template is .

XPath expressions are classified using the rules in this section.

In the analysis that follows, expressions are classified according to the most specific production rule that they match for which there is an entry in this section. A production P is considered more specific than a production Q (Q ≠ P) if every expression that matches P also matches Q. For example:

The production rules for different kinds of expression are listed (with their names and numbers) in the order in which they appear in Appendix A.1 of the XPath 3.0 specification; rules are also given for new constructs introduced by XPath 3.1. Where two numbers are given, they are the production rule numbers in XPath 3.0 and XPath 3.1 respectively; where there is a single number, it is the production rule number in XPath 3.1.

Many expressions can be analyzed using the . These are indicated in the table below by means of a simple proforma in which the operand roles are represented by a short code (A = , I = , T = , N = ). For example the proforma A + A indicates that for an arithmetic expression, both operands have , while I or I indicates that for an or expression, both operands have . For expressions where further explanation is needed, the table contains a link to the relevant section.

This section describes the rules that determine the streamability of calls to built-in functions. These differ from user-written functions because it is known (defined in the specification) how nodes supplied as operands are used. Knowledge of the usage of each operand, together with the of the actual operands, is in most cases enough to determine the and of the function result.

All the built-in functions are listed below. For most functions, a simple proforma is shown that indicates the operand usage of each argument, using the code (A = , I = , T = , N = ). So, for example, the entry fn:remove(T, A) means that for the function fn:remove#2, the of the first argument is , and the of the second argument is . By reference to the general rules in , this demonstrates that if the is , the posture and sweep of the expression sum(remove(*,1)) will be grounded and consuming respectively.

For functions that default one of their arguments (typically to the context item), the relevant entry shows the equivalence, and the posture and sweep can in these cases be computed by filling in the default value for the relevant argument.

Some functions do not follow the general rules, and these are listed with a link to the section where the particular rules for that function are described.

The of a is either or . (Although there are patterns that could in principle be evaluated by consuming the element node that they match, these are of no interest in the analysis, so they are classified as free-ranging.)

The of a is if the pattern is , or otherwise. (This reflects the fact that a pattern always returns a boolean result; it never returns a node in a streamed document.)

Informally, a pattern is one that can be evaluated by a streaming processor when the input stream is positioned at the start of the node being matched, without advancing the input stream.

A pattern is if and only if it satisfies all the following conditions:

A predicate is a non-positional predicate if it satisfies both of the following conditions:

A non-positional predicate can be evaluated by considering each item in the filtered sequence independently; the result never depends on the position of other items in the sequence or the length of the sequence.

A pattern that is not is classified as .

The following list shows examples of motionless patterns:

The following list shows examples of patterns that are not motionless, explaining why not:

The examples in this section are intended to illustrate how the streamability rules are applied “top down” to establish whether template rules are guaranteed streamable.