Bug #2557: <xsl:evaluate with-params="$map"/> does not seem to work - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2557

closed

<xsl:evaluate with-params="$map"/> does not seem to work

Added by Pieter Masereeuw over 8 years ago. Updated over 8 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

XSLT conformance

Sprint/Milestone:

Start date:

2015-12-22

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7

Fix Committed on Branch:

9.7

Fixed in Maintenance Release:

9.7.0.2

Platforms:

Description

Saxon crashes when it tries to evaluate the following statement:

<xsl:evaluate xpath="$xpath2" with-params="$map"/>

I attach a stylesheet that reproduces the problem and also its output.

Although the traceback mentions a ClassCastException, the problem also exists if I try another expression, such as concatenating strings.

Input can be any XML file, including the stylesheet itself.

Or am I misinterpreting the specs?

Files

Download all files

output.txt (1.49 KB) output.txt		Pieter Masereeuw, 2015-12-22 08:47
testmap.xslt (908 Bytes) testmap.xslt		Pieter Masereeuw, 2015-12-22 08:47

Actions

Copy link

Updated by Michael Kay over 8 years ago

I get the error

java.lang.ClassCastException: net.sf.saxon.value.StringValue cannot be cast to net.sf.saxon.value.QNameValue

This is because the keys in the parameter map should be QNames (instances of xs:QName) rather than strings.

But of course Saxon should fail with a proper error message, not with a ClassCastException.

I have added this as test case evaluate-043 to the W3C XSLT 3.0 test suite.

Actions

Copy link

Updated by Michael Kay over 8 years ago

Category set to XSLT conformance
Status changed from New to Resolved
Assignee set to Michael Kay
Priority changed from Low to Normal
Applies to branch 9.7 added
Fix Committed on Branch 9.7 added

I'm assuming you were running 9.7. With 9.6, Saxon reports that the @with-params attribute is not yet implemented.

I've committed a patch to return a proper error message. I found that there wasn't an error code allocated in the XSLT 3.0 specification (though it's clear that the key must be an xs:QName) and I have raised bug 29351 [1] to propose that we allocate code XTTE3165 to this condition.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=29351

Actions

Copy link