Project

Profile

Help

Bug #5766

closed

xsl:evaluate, duplicated params in @with-params and child::xsl:with-param - test case evaluate-018d

Added by Michael Kay over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2022-12-15
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
11, trunk
Fix Committed on Branch:
11, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

This test is passing on SaxonJ 12 and failing on SaxonCS 12.

The test expects a type error, which is not being reported in SaxonCS.

I think the test is questionable. It supplies parameters to xsl:evaluate both using the @with-params attribute (dynamic parameters) and using a child xsl:with-param instruction. The spec says that the former take precedence. The type error comes from the xsl:with-param instruction. I think in this situation both reporting the type error and not reporting it are legitimate; but there's a question as to why SaxonJ and SaxonCS are behaving differently.

Actions #1

Updated by Michael Kay over 1 year ago

On both platforms we are evaluating the xsl:with-param (unnecessarily). But for some reason on SaxonJ the select expression has been promoted to a global variable, which is evaluated eagerly, triggering the type error; but on SaxonCS this promotion has not taken place, so the value is evaluated lazily, and since it is never used, the type error is not triggered.

So the question becomes: why is the promotion to global happening in SaxonJ but not in SaxonCS?

Actions #2

Updated by Michael Kay over 1 year ago

It seems the SaxonCS test driver is running with JIT compilation of template rules enabled, while the SaxonJ test driver is running with this option disabled. When JIT compilation is enabled, we don't attempt to extract global variables from templates (because we don't want to create new global variables dynamically). Both paths are legitimate, and it does no harm that we're exercising different options...

The real issue is, we shouldn't be evaluating xsl:with-param instructions that aren't needed because they are overridden by dynamic params.

Which in turn means that the test case shouldn't be expecting the type error to be reported.

Actions #3

Updated by Michael Kay over 1 year ago

I've now

(a) updated the code (12.x branch) so it doesn't evaluate the xsl:with-param if there's a dynamic parameter with the same name

(b) modified the test so it forces the xsl:with-param to be evaluated

Actions #4

Updated by Michael Kay over 1 year ago

  • Project changed from 20 to Saxon
  • Subject changed from XSLT3 test case evaluate-018d to xsl:evaluate, duplicated params in @with-params and child::xsl:with-param - test case evaluate-018d
  • Category set to XSLT conformance
  • Status changed from New to Resolved
  • Applies to branch 11, trunk added
  • Fix Committed on Branch 11, trunk added
  • Platforms .NET, Java added
Actions #5

Updated by Community Admin over 1 year ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 12.0 added

Bug issue fix applied in the Saxon 12.0 Major Release. Leaving this bug marked as Resolved until fix applied

Actions #6

Updated by O'Neil Delpratt about 1 year ago

  • Fixed in Maintenance Release 11.5 added

Bug applied in the Saxon 11.5 Maintenance release.

Actions #7

Updated by O'Neil Delpratt about 1 year ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF