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 22936 - [XSLT 3.0] Streamability : dynamic calls to context dependent functions
Summary: [XSLT 3.0] Streamability : dynamic calls to context dependent functions
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working drafts
Hardware: PC All
: P2 normal
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: 2013-08-13 10:35 UTC by Michael Kay
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2013-08-13 10:35:42 UTC
We say that a NamedFunctionRef is motionless.

Similarly we have no special rules for function-lookup().

However, in both cases these constructs are not as innocent as they seem, because they capture the dynamic context at the point they are evaluated, and use that dynamic context later when the resulting function is called.

For example:

<xsl:variable name="saved-current" select="current#0"/>
<xsl:for-each select="transaction">
  <xsl:if test="value = $saved-current()/value">
    ...
  </xsl:if>
</xsl:for-each>

is clearly not streamable.

So:

(a) A NamedFunctionRef should be free-ranging if the function is dependent on (relevant parts of?) the dynamic context

(b) function-lookup() should always be free-ranging (because we have no way of knowing what it might do).

(c) Partial function application could also be dangerous in the same way if we had any focus-dependent functions with two or more arguments. Fortunately we don't, though it seems a little odd to assume that.
Comment 1 Michael Kay 2013-09-24 16:53:23 UTC
Noted that partial function application is currently already free-ranging - we're not sure why. We think this restriction should be removed.

For the other cases we agree that the use of focius-dependent functions should be restricted. For function-lookup() we think this should be a dynamic error so that we don't ban all uses of function-lookup(), most of which will be perfectly innocent.
Comment 2 Michael Kay 2013-09-24 22:00:10 UTC
I'm re-opening this in respect of the rules for function-lookup(). We suggested that this should return a dynamic error if (when streaming?) the function actually selected is a focus-dependent function. However, it's not clear what the actual circumstances for this error should be. In addition, raising such an error would require modification to the XPath specification of function-lookup(), which we should avoid if possible.
Comment 3 Michael Kay 2013-09-25 15:38:37 UTC
We looked again at the function-lookup case and it starts to make more sense.

Given $f := function-lookup("fn:lang", 1) followed by $f("en"), this is supposed to test the language of the node that was the context item at the time function-lookup was called. If this was a node in a streamed document, we can't safe a reference to it in the function closure. So we should define that in this case, in the closure we set the context item to "absent", which leads to a dynamic error if and when $f("en") is actually called.
Comment 4 Michael Kay 2013-09-26 07:07:55 UTC
Spec updated (section id = #function-lookup)