[Bug 25160] New: [XSLT 3.0] a//c with striding CP is roaming by the rules, though we strove to make it streamable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25160

            Bug ID: 25160
           Summary: [XSLT 3.0] a//c with striding CP is roaming by the
                    rules, though we strove to make it streamable
           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

Under [1] we write that // must be rewritten as /descendant-or-self::node()/
and an omitted axis x to child::x. Following the rules we get, given a context
posture of striding:

1. rewrite a//c as child::a/descendant-or-self::node()/child::c
2. rewrite for associativity as (child::a/descendant-or-self::node())/child::c
3. determine LH posture and sweep
  a. assess child::a/descendant-or-self::node()
  b. determine LH posture and sweep
     i. assess child::a with CP striding
     ii. table under 19.8.7.7 gives result posture striding, sweep consuming
  c. determine RH posture and sweep
     i. assess descendant-or-self::node() with CP striding
     ii. table under 19.8.7.7 gives result posture crawling, sweep consuming
4. determine RH posture and sweep
  a. assess child::c with CP crawling
  b. table under 19.8.7.7 gives result posture roaming, sweep free-ranging
5. result of a//c is roaming and free-ranging

The problem in the rules is with the rewriting of // into
/descendant-or-self::node()/, which introduces an extra step. Were we to
rewrite a//c as a/descendant-or-self::c, the problem would not arise.

I propose to augment the rule for rewriting // as follows:

//x and //child::x into /descendant::x
//otheraxis::x into /descendant-or-self::node()/otheraxis::x
//otherexpr into /descendant-or-self::node()/otherexpr

Note also that we say very explicitly that a//c should be streamable (well,
crawling, so streamable in certain contexts, like xsl:for-each) in the second
bullet point under Examples of 19.8.7.6: 

"If the context posture is striding, then the posture of the expression a//c is
crawling, because a descendant axis step evaluated with striding posture
creates a new crawling posture."

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 26 March 2014 17:27:56 UTC