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 24546 - Determinism, caching, memoization in relation to functions and variables
Summary: Determinism, caching, memoization in relation to functions and variables
Status: CLOSED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: 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: 2014-02-05 23:51 UTC by Abel Braaksma
Modified: 2014-05-15 14:00 UTC (History)
1 user (show)

See Also:


Attachments

Description Abel Braaksma 2014-02-05 23:51:19 UTC
It is currently not clear what happens if someone were to write the following:

<xsl:variable name="time">
   <xsl:stream href="http://timsrvr/current-time.php">
      <xsl:value-of select="/time/@current-time" />
   </xsl:stream>
</xsl:variable>

Because xsl:stream is non-deterministic and is allowed to return different results when called multiple times, and because it is likely that processors process a variable only once, this construct may not deliver what people might expect.

This is even more apparent with functions and the new cache attribute:

<xsl:function name="f:time" cache="no">
   <xsl:stream href="http://timsrvr/current-time.php">
      <xsl:value-of select="/time/@current-time" />
   </xsl:stream>
</xsl:function>

Because caching is currently a non-mandatory hint, again this might not do what a user expects, and the result may well be different between different processors, or even between invocations of the same processor.

I propose to resolve this by removing cache="no", which may not do what users expect, but instead use cache="default", which leaves it to the processor, and cache="never", which is a mandatory hint to the processor to actually never cache the results.

We could extend this to variables, though that might raise some eyebrows. Or we can leave it as-is for variables (implementation defined), perhaps with an added Note that explicitly says what might happen in such situations.
Comment 1 C. M. Sperberg-McQueen 2014-02-12 16:30:39 UTC
We discussed this at the face to face meeting in Prague.  There were varying views on how far the expectations of the imaginary user are rational or justified or consistent with the spec, and on how far it is possible for users to force multiple evaluations of function calls and how far it is possible for implementors to evade the users' efforts in this regard.

No action.