Project

Profile

Help

Bug #6636

closed

"The required type is xs:nonNegativeInteger; the supplied value 60 does not match. The supplied value type is xs:integer"

Added by Dimitre Novatchev 19 days ago. Updated 14 days ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2025-01-07
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:
Java

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 ** "

Actions #1

Updated by Dimitre Novatchev 19 days ago

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>
Actions #2

Updated by Michael Kay 19 days ago

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

Actions #3

Updated by Dimitre Novatchev 19 days ago

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?

Actions #4

Updated by Michael Kay 19 days ago

Shouldn't there be "coercion" that seems quite possible

We introduced this in 4.0.

Actions #5

Updated by Dimitre Novatchev 19 days ago

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. "

Actions #6

Updated by Michael Kay 14 days ago

  • 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