W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2014

[Bug 24546] New: Determinism, caching, memoization in relation to functions and variables

From: <bugzilla@jessica.w3.org>
Date: Wed, 05 Feb 2014 23:51:19 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24546-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24546

            Bug ID: 24546
           Summary: Determinism, caching, memoization in relation to
                    functions and variables
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 5 February 2014 23:51:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:45 UTC