This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24549 - Primed stylesheets, execution scope and stability of functions
Summary: Primed stylesheets, execution scope and stability of functions
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-06 00:14 UTC by Abel Braaksma
Modified: 2014-03-04 14:54 UTC (History)
1 user (show)

See Also:


Attachments

Description Abel Braaksma 2014-02-06 00:14:11 UTC
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.
Comment 1 C. M. Sperberg-McQueen 2014-02-13 09:42:56 UTC
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"?).
Comment 2 Michael Kay 2014-02-21 15:26:52 UTC
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.
Comment 3 Abel Braaksma 2014-03-04 14:54:56 UTC
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.