Re: Is this correct: " A sequence of more than one ite

Hi Michael,

Thank you for the explanation. I found the same immediately after
posting the initial message and then posted another, asking to
disregard the first.

What was/is confusing, though, was/is the error message. I believe it
can be improved to provide more information.

Finally, and most importantly, do get well soon.

Dimitre



On Tue, Jun 17, 2014 at 5:27 AM, Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> You declared $g to expect a single item as its argument, but in the call
$g($x), $x is bound to a sequence of more than one item. Even though $g is
bound to a function (reverse#1) that accepts multiple items, I think the
function coercion rules expect the call to satisfy the declared type.
>
> Michael Kay
> Saxonica
> mike@xxxxxxxxxxxx
> +44 (0118) 946 5893
>
>
>
> On 15 Jun 2014, at 00:45, Dimitre Novatchev dnovatchev@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> I have this transformation:
>>
>> <xsl:stylesheet  version="3.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>> <xsl:template match="/">
>>   <xsl:sequence select=
>>    "function($f as function(item()*) as item(),
>>              $g as function(item()) as item()*,
>>              $x as item()*
>>              ) as item()*
>>     { $f($g($x)) }
>>          (head#1, reverse#1, ('H','e','l','l','o'))
>>    "/>
>> </xsl:template>
>> </xsl:stylesheet>
>>
>> When I use BaseX to evaluate the XPath 3.0 expression that is
>> specified in the "select" attribute of the <xsl:sequence> above, I get
>> the expected, correct result:
>>
>>            "o".
>>
>> However, when I run this transformation with the Saxon-EE 9.5.1.3 from
>> within Oxygen, I get this error:
>>
>> Severity: fatal
>> Description: XPTY0004: A sequence of more than one item is not allowed
>> as the first argument of dynamic function call ("H", "e", ...)
>> URL: http://www.w3.org/TR/xpath20/#ERRXPTY0004
>>
>> I have never heard of any such limitation before, haven't seen such a
>> rule in any specification and cannot find any reasons for such
>> limitation.
>>
>> Could someone, please, explain if this behavior is a bug, or not? If
>> this is correct behavior, what is the rationale behind this
>> limitation?