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

[Bug 29442] New: [XSLT30] Impossible to return maps, functions, arrays, sequence of integers or doubles from xsl:functions, xsl:templates, xsl:sequence etc

From: <bugzilla@jessica.w3.org>
Date: Tue, 09 Feb 2016 19:49:44 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29442-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 29442
           Summary: [XSLT30] Impossible to return maps, functions, arrays,
                    sequence of integers or doubles from xsl:functions,
                    xsl:templates, xsl:sequence etc
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          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
  Target Milestone: ---

I have tried reading this several times and keep reading in circles, so I think
there is a bug. 

1) Say you have:

<xsl:template match="/">
   <xsl:map-entry key="foo" select="42" />

You now have an xsl:template instruction with a sequence constructor. Following
the rules in 5.7 we end up at Rule 8: raise XTDE0450 when the sequence contains
a function item.

2) Say you have:

<xsl:function name="f:foo">
   <xsl:sequence select="name#1" />

Same as in (1), you have to raise XTDE0450 on every function call.

3) Say you have:

<xsl:variable name="f:arr" as="array(*)">
   <xsl:sequence select="arr:create(1)" />

Different from (1), as in Rule 2 we have to flatten the array first. After
flattening, it becomes a sequence of atomics, which are cast to a string. This
is not roundtrippable, so the result (the "supplied value") cannot be cast back
to an array.

4) Say you have:

<xsl:function name="f:find" as="xs:integer*">
    <xsl:for-each select="1 to 10">
        <xsl:if test=". = (5, 7)">
            <xsl:sequence select="." />

Here the inner seqtor returns two single integers, that are atomized (Rule 3)
and cast to a string. The seqtor or xsl:for-each returns thus a sequence of two
string "5" and "7". These are concatenated into the string "5 7" which is now
not castable to xs:integer* anymore, failing each time with a cast error.

5) Example from 11.10 in the spec

<xsl:variable name="values" as="xs:integer*">
    <xsl:sequence select="(1,2,3,4)"/>
    <xsl:sequence select="(8,9,10)"/>

For the same reasons as (4), this will fail.

6) Say you have:

<xsl:variable name="txt" as="text()">

If you evaluate this you end up with Rule 7: adjacent text nodes are merged
into one. That means that the above example should work and NOT throw an error,
however most implementations (Saxon and Exselt for one) throw a cast error

I think it is debatable what should happen here. I have create two tests,
seqtor-041, seqtor-042 to that effect.

7) Rule 11

The above examples were written without Rule 11 in mind, which reads:

"Each node in the resulting sequence is attached as a namespace, attribute, or
child of the newly constructed element or document node."

That means that *each and every* sequence constructor we encounter creates
nodes. That is clearly not what is supposed to happen.


The above examples are supposed to be a literal reading of this part (section
5.7) of the spec. It is very well possible that I miss the obvious here,
because all example, except perhaps for item (6) are without a doubt not how
these instructions are supposed to behave.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 9 February 2016 19:49:47 UTC

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