Project

Profile

Help

Bug #6011

closed

Inline function created using xsl:evaluate

Added by Michael Kay 11 months ago. Updated 11 months ago.

Status:
Rejected
Priority:
Normal
Category:
XSLT Conformance
Sprint/Milestone:
-
Start date:
2023-05-03
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

Same bug as #6003, but on SaxonJS.

Actions #1

Updated by Debbie Lockett 11 months ago

As reported by Martin, the failure with SaxonJS 2 is different:

xslt3 -t -s:Downloads\evaluationTest.xml -xsl:Downloads\validation.xslt
SaxonJS 2.5 from Saxonica
Node.js version v16.17.1
Compiling stylesheet C:\Users\marti\Downloads\validation.xslt
Stylesheet compilation time: 0.249s
Asynchronous transform with options: stylesheetText={"N":"package","version":"20",(string), stylesheetBaseURI=file://C:/Users/marti/Download(string), stylesheetParams=[object Object](string), outputProperties=[object Object](string), extraOptions=[object Object](string), destination=stdout(string), baseOutputURI=file://C:/Users/marti/(string), logLevel=2(string), sourceFileName=file://C:/Users/marti/Download(string),
SEF generated by SaxonJS 2.5 at 2023-05-01T22:27:47.954+02:00
 in root of document
<?xml version="1.0" encoding="UTF-8"?>
<innings>
   <number>1</number>
   <battingSide>yorkshire</battingSide>
   <fieldingSide>lancashire</fieldingSide>
   <over>
      <bowler>1</bowler>Transformation failure: Error XTTE0570 at validation.xslt#39
  Required item type of value in 'xsl:variable name="Q{}read_function"' expression is (function(element(*)) as element(*)?); supplied value is anonymous function (arity 1)
Error XTTE0570 at validation.xslt#39
  Required item type of value in 'xsl:variable name="Q{}read_function"' expression is (function(element(*)) as element(*)?); supplied value is anonymous function (arity 1)

And in fact, this error is correct, though the error message does not give quite enough information to make this clear. The supplied anonymous function will not pass the type checking because its function type is not a subtype of function(element(*)) as element(*)?

The signature of the supplied anonymous function is either function(element(innings)) as element(side) or function(element(over)) as element(player), as specified in the function declarations in the source evaluationTest.xml.

But for function types, function(A) as B is a subtype of function(C) as (D) requires that B is a subtype of D, and C is a subtype of A, not the other way round (see https://www.w3.org/TR/xpath-31/#id-sequencetype-subtype).

Actions #2

Updated by Debbie Lockett 11 months ago

To avoid this type checking error, I think it is necessary to be less specific for the types of the arguments in the XPath function declarations in evaluationTest.xml:

  • use function($instance as element()) as element(side) instead of function($instance as element(innings)) as element(side) on line 6
  • use function($instance as element()) as element(player) instead of function($instance as element(over)) as element(player) on line 12

To then get the test to run correctly, I also needed to correct line 14 in evaluationTest.xml:

  • $lib?readRel($instance/parent::element(innings), 'fieldingSide') rather than $lib?readRel($instance, 'fieldingSide')
Actions #3

Updated by Debbie Lockett 11 months ago

  • Status changed from New to Rejected

With these code fixes, the supplied test runs without error in SaxonJS 2. I have also verified that the test Martin supplied for bug #6004 also runs correctly in SaxonJS 2. (I have not yet run Mike's XSLT30 test because I don't see it committed yet.)

So I believe this is user error, rather than a SaxonJS bug; so I'm marking it rejected.

Actions #4

Updated by Debbie Lockett 11 months ago

Can now confirm that the new XSLT30 tests evaluate-051 and evaluate-052 also pass with SaxonJS 2.

Actions #5

Updated by John Lumley 11 months ago

Getting the types for function items can be pretty tricky as the arguments reverse the sense of 'subtype' (It can help to think of two sets of Venn diagrams, one in the range, i.e. function output, and on one in each of the argument domains.) To be a same-or-subtype the (output) range must really be a same-or-subtype of the required type of the function call use. But for the all the arguments it must be the other way round: the expected type of each function argument must be self-or-supertype of the supplied call argument.

This of course becomes even more convoluted in higher-functions where the arguments to the function themeselves are functions and potentially their arguments type 'flip' the subtype sense yet again.

Please register to edit this issue

Also available in: Atom PDF Tracking page