Project

Profile

Help

Bug #2898

closed

The second argument of saxon:serialize must either be a string literal, or an xsl:output element

Added by Michael Kay over 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Saxon extensions
Sprint/Milestone:
-
Start date:
2016-08-23
Due date:
% Done:

100%

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

Description

Reported on saxon-help mailing list by Andrew Welch

This xslt:

<xsl:stylesheet version="2.0"

xmlns:saxon="http://saxon.sf.net/"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output name="aaa"/>

<xsl:variable name="chunk">

   <chunk/>

</xsl:variable>

<xsl:template match="/">

   <xsl:value-of select="saxon:serialize($chunk, 'aaa')"/>

</xsl:template>

</xsl:stylesheet>

fails in 9.7.0.7 with:

"The second argument of saxon:serialize must either be a string literal, or an xsl:output element"

but succeeds in 9.6.0.9

Equally a second arg of '' fails in 9.7.0.7, fine in previous versions.

Actions #1

Updated by Michael Kay over 7 years ago

I've reproduced this. saxon:serialize is implemented as an integrated extension function, and implements a method

public void supplyStaticContext(StaticContext env, Location locationId, Expression[] arguments) throws XPathException {

which it expects to be called at compile time to supply static information about the stylesheet (so it can find the xsl:output declaration). But the method isn't being called, and that's because it fails to override the method declared in the superclass which is

public void supplyStaticContext(StaticContext context, int locationId, Expression[] arguments) throws XPathException {

An absolutely classic Java coding error, that goes undetected because there is no @Override annotation.

(The odd error message arises because this method sets up data if the argument is a string literal, and if that data is null then at run time the code is assuming that the argument can't have been a string literal).

I suspect the trigger for the problem was that I dithered about making a backwards-incompatible change to this public interface. The problem is that integer location id's are meaningless in 9.7, as a consequence of the modular compilation of packages. Generally everything has changed to using a Location object instead. So it seems I half made the change, and it broke as a result.

Actions #2

Updated by Michael Kay over 7 years ago

Fixed on the 9.7 branch by changing the Serialize version of the method to expect an integer locationId (which is useless, but it's only used for diagnostics).

On the 9.8 branch a different change is needed because the function has been reimplemented as a SystemFunction.

Also need to add a test case.

Actions #3

Updated by Michael Kay over 7 years ago

It seems that our only test cases for this function were inadvertently changed to use fn:serialize().

Actions #4

Updated by Michael Kay over 7 years ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 9.7, 9.8 added

Patches committed on the 9.7 and 9.8 branches; unit test cases added (in xslt30-extra)

Actions #5

Updated by O'Neil Delpratt over 7 years ago

  • % Done changed from 0 to 100

Bug fix applied in the Saxon 9.7.0.8 maintenance release.

Actions #6

Updated by O'Neil Delpratt over 7 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.7.0.8 added
Actions #7

Updated by O'Neil Delpratt almost 7 years ago

  • Applies to branch trunk added
  • Applies to branch deleted (9.8)
Actions #8

Updated by O'Neil Delpratt almost 7 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)

Please register to edit this issue

Also available in: Atom PDF