Bug #6636
closed
"The required type is xs:nonNegativeInteger; the supplied value 60 does not match. The supplied value type is xs:integer"
Fixed in Maintenance Release:
Description
This is the essence of the error message by Saxon 12.4 (I am told that the same happens in 12.5).
" The required type is xs:nonNegativeInteger; the supplied value 60 does not match. The supplied value type is xs:integer ** "
The stylesheet is:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:template match="/">
<xsl:sequence select=
"let $myFun := function($n as xs:nonNegativeInteger)
{
$n + 1
}
return $myFun(60)"/>
</xsl:template>
</xsl:stylesheet>
Interestingly enough, just adding a return type to $myFun, so that now it reads:
let $myFun := function($n as xs:nonNegativeInteger) as xs:integer
produces another interesting, but totally different error message:
" XTTE0780 An item of type xs:double cannot be converted to xs:integer as required for the
result of a call to anon:f_951221468#1
In template rule with match="/" on line 7 of marrowtr.xsl
An item of type xs:double cannot be converted to xs:integer as required for the result of a call to anon:f_951221468#1 ** "
This is the essence of the error message by Saxon 12.4 (I am told that the same happens in 12.5).
" The required type is xs:nonNegativeInteger; the supplied value 60 does not match. The supplied value type is xs:integer "
The stylesheet is:
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:template match="/">
<xsl:sequence select=
"let $myFun := function($n as xs:nonNegativeInteger)
{
$n + 1
}
return $myFun(60)"/>
</xsl:template>
</xsl:stylesheet>
In both cases I think Saxon is behaving correctly according to the XSLT 3.0 specification. (Though of course, it is always possible to find improvements to error messages).
Downcasting the supplied xs:integer
value to xs:nonNegativeInteger
is allowed in 4.0 but not in 3.0. - in 4.0, the call is permitted.
The second case is more surprising. Why should adding an xs:nonNegativeInteger
to an integer produce an xs:double
?
I'm having difficulty reproducing this. I get the same error
XPTY0004 The required item type of the first argument of function($n){$n + 1}() is
xs:nonNegativeInteger; the supplied value 60 does not match. The supplied value is of type
xs:integer
However, the two versions of the stylesheet that you posted are different. The first one has version="1.0"
, the second has version="3.0"
. The failure occurs when you specify version="1.0"
, because in 1.0-compatibility mode the result of an arithmetic expression is always an xs:double
Downcasting the supplied xs:integer value to xs:nonNegativeInteger is allowed in 4.0 but not in 3.0. - in 4.0, the call is permitted.
Shouldn't there be "coercion" that seems quite possible: from an xs:integer that is non-negative, to an xs:nonNegativeInteger?
Otherwise, how should the call be specified?
$myFun(xs:nonNegativeInteger(60))
Does XPath 3.1 prohibit the coercion and require explicit construction?
Shouldn't there be "coercion" that seems quite possible
We introduced this in 4.0.
Shouldn't there be "coercion" that seems quite possible
We introduced this in 4.0.
Then we need a better error message, saying: " If the supplied xs:integer value is greater than 0, pass the argument as an xs:nonNegativeInteger, explicitly constructed from this value. "
- Status changed from New to Rejected
Improving error messages is always possible, but sometimes it involves passing a lot of extra information down the call stack so that the method that detects the error knows what the user was trying to do at the time. So each case has to be considered on its merits. I've looked at this example and decided after due consideration to make no change.
Please register to edit this issue
Also available in: Atom
PDF