This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Under 2.3.2 Priming a Stylesheet (http://www.w3.org/TR/xslt-30/#priming-stylesheet), after the bulleted list, first paragraph, the text reads: "In addition, priming a stylesheet creates an execution scope during which the dynamic context and all function calls remain stable;" With the advent of xsl:stream and friends, it is not true anymore that "all function calls remain stable". It is only true for those function calls that do not have streamable side effects.
We discussed this in Prague. In reviewing the section to get a sense of the context, we noticed a couple of points not directly relevant to this bug report: - The note in the first bullet item of 2.3.2 is not quite right; it has now been arranged that no two packages can declare stylesheet parameters with the same name. (Or so we now believe.) - Paragraph 2 in bullet item 2 is not quite wrong, but feels misleading: the context item for the initialization of global variables and parameters is not the initial context item but its root. The "use" of the initial context item for initialization of global variables is thus rather indirect. On the point initially raised here: the reference to 'all' functions is too broad, as the point does not apply to unstable functions. Possible fix: for "all functions" read "deterministic functions". Or "... creates an execution scope. As defined elsewhere, this has as a consequence that deterministic functions called within that execution scope with the same arguments will return the same results.") When we followed the link to F and O, we discovered that it does not explicitly connect identity of execution scope to the expectation that deterministic functions will return identical results for identical arguments (need to insert "within a given execution scope" before "repeated calls with the same explicit and implicit arguments must return identical results"?).
The note in the first bullet of 2.3.2 is in fact correct; but it's confusing, because it refers to static parameters, whereas the preceding text refers to non-static parameters. The note should draw out this contrast. Concerning the second bullet of 2.3.2, the "traditional API" was to provide a single node as input, and in the language of the new spec, this node served as the initial input sequence (for selecting the apply-templates entry point), while the root of the containing tree provided the "initial context item". This relationship is now being portrayed as a characteristic of some legacy APIs rather than as an inevitable feature of every API. The F+O problem has been raised in a separate bug report: bug #24646.
For completeness and historical accuracy: the previous comment does not mention that a fix was applied to refer to deterministic functions in the first para after the bulleted list in 2.3.2, as was the suggestion in comment 1, third para. This fix has now been applied.