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 section 19.8.7.9 Streamability of Dynamic Function Calls (http://www.w3.org/TR/xslt-30/#streamability-of-dynamic-function-calls) we say in the last paragraph: "The operand usage for the other operands (the argument expressions) is in general navigation, because it is not known how the function will make use of any supplied nodes. However, if the static type of the first operand constrains the type of the argument to be atomic, then the operand usage for that argument becomes absorption, and if it constrains it to be a function, the operand usage becomes inspection." The whole paragraph could be rewritten to refer to the already existing type determined usage. If that is not appropriate, the second sentence in this paragraph is ambiguous: do we mean the "first operand" in respect to the first paragraph, i.e. $F, or do we mean the first argument? I think we mean the static type of $F, which can be, for instance, function(xs:string), which has posture absorption for its first argument. In addition, we don't say anything about potential error conditions. For instance, if $F refers to last#0, we should raise a dynamic error (if used in an illegal spot). In other words, the expression $F and its arguments can be streamable, but the actual call is not, which can only be determined once the call is made.
We discussed this at the Prague face to face. We agreed that the first two paragraphs raise editorial issues that should receive attention. On the error conditions, some WG members expressed surprise; surely we have discussed this issue and dealt with it? Section 10.3.5 needs a bit of generalization: it talks about functions that use the context item, but not about functions that use context size or position. Also, there should be links to 10.3.5 from 19.8.7.9 (i.e. #streamability-of-dynamic-function-calls).
Proposed rewrite of the section 19.8.7.9 as follows (note, the term "base expression" is taken from the description of dynamic function calls in the XPath 3.0 book): The posture and sweep of a dynamic function call such as $F(X, Y) are determined by the *general streamability rules*. The operands and their usages are as follows: * The base expression that computes the function value itself (here $F) has usage inspection * The argument expressions (here X and Y) have type-determined usage determined from the static type of the base expression. If the static type of the base expression is of the form function(A, B) as R, then the first argument X has type-determined usage based on the first argument type A, the second argument Y has type-determined usage based on the second argument type B, and so on. If the static type of the base expression is not of this form (for example, it it is item()), then the usage of each of the argument expressions is navigation. Note: As explained in 10.3.5, use of a dynamic function call where the function is bound to a focus-dependent function such as name#0, lang#1, or last#0 when streaming is likely to lead to a dynamic error, but this does not affect the static streamability analysis. In 10.3.5, last para, change "context-dependent" to "focus-dependent", add last#0 to the examples, and change "context item" to "focus".
The proposal in comment 2 was accepted.
This change had in fact been applied to the spec some while ago.