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

[Bug 30064] New: [xslt30ts] Test case function-5006

From: <bugzilla@jessica.w3.org>
Date: Wed, 15 Feb 2017 20:56:12 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-30064-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 30064
           Summary: [xslt30ts] Test case function-5006
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0 Test Suite
          Assignee: abel.online@xs4all.nl
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

I'm struggling a bit with this test, which reads:

    <xsl:template match="/">
select="outermost(doc/sf:deep-descent(section[1]))/text()" >
                <xsl:copy-of select="self::text()" />

    <xsl:function name="sf:deep-descent" streamability="deep-descent"
        <xsl:param name="node" as="node()"/>
        <xsl:sequence select="$node//section//p" />

First observation is that if we inline the function, we get 

    <xsl:for-each select="outermost(doc/section[1]//section//p)/text()" >
        <xsl:copy-of select="self::text()" />

and this isn't streamable (you can't use the descendant axis from crawling
posture, unless you're covered by the exemption for scanning expressions, which
doesn't apply here because doc/section[1]//section//p is not a motionless
pattern, because of the numeric predicate).

It would seem a bit surprising if the function call should be streamable when
the result of inlining it isn't.

The rules for deep-descent functions say that the function body must be
crawling. That will only be the case if $node//section//p is a scanning
expression, which requires it to be equivalent to a motionless pattern. But a
pattern cannot be a motionless pattern if it contains a RootedPath, which this
does (the variable reference at the start).

This is somewhat legalistic wriggling: I can't see why the function can't be
implemented using the scanning approach. But I don't think it passes the
current rules.

So I don't think this test passes the streamability rules.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 15 February 2017 20:56:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:03 UTC