W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2013

[Bug 24173] New: [xslt 3.0] Need more precise type information

From: <bugzilla@jessica.w3.org>
Date: Sat, 28 Dec 2013 17:32:13 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24173-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 24173
           Summary: [xslt 3.0] Need more precise type information
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

John Lumley writes:

When working through the W3C test sets (fix one problem, open up another.....)
I think I've discovered some cases where more precise type determination is
required. This is typified in strm/sf-head/sf-head-A.xsl, test r-32 and the
xsl:value-of/@select. The circumstances are:

The argument to fn:head() has type attribute()*, climbing posture and consuming

As the usage of that argument is transmission and it is the sole potential
consumer, the call to fn:head() has climbing posture and consuming sweep.

The functional signature type of fn:head() is item()?

The (un-adjusted) usage of this call by xsl:value-of is absorption, which with
a climbing posture gives the xsl:value-of a free-ranging sweep and thus a
roaming posture.

The issue is that of the type of fn:head() - in this case any of the members of
the argument sequence have type attribute() and would be classed as
childless-nodes. If in this circumstance we classify the type of fn:head() to
be attribute()?, then the usage is this call by xsl:value-of is adjusted to
inspection by rule 1.b.iii.A.I, and thus the sweep remains as consuming, the
call is a single potentially consuming operand with inspection usage, so the
xsl:value-of becomes grounded and motionless.

So it appears that without a finer type determination, viz the type of
fn:head() is effectively the (singular) type of its first argument, this
example can't be guaranteed streamable.

I think similar conditions would also apply to 
'outermost','innermost','exactly-one','zero-or-more','one-or-more','trace' -
the tests fail without such type determination.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Saturday, 28 December 2013 17:32:15 UTC

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