Project

Profile

Help

Bug #2219

closed

xsl:next-match; patterns using match="$var" syntax

Added by Michael Kay about 10 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
Start date:
2014-11-12
Due date:
% Done:

100%

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

Description

Reported by Martin Honnen on saxon-help list.

Using Saxon 9.6 PE when I run the following stylesheet

<xsl:stylesheet version="3.0"

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

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:xf="http://www.w3.org/2005/xpath-functions"

xmlns:new="http://example.com/new"

exclude-result-prefixes="xs xf">

<xsl:variable name="start-node" as="text()?"

select="root/p[1]/span[1]/text()"/>

<xsl:variable name="end-node" as="text()?"

select="root/p[2]/span[1]/text()"/>

<xsl:template match="@* | node()">

xsl:copy

<xsl:apply-templates select="@* , node()"/>

</xsl:copy>

</xsl:template>

<xsl:template match="$start-node" priority="5">

new:start/

xsl:next-match/

</xsl:template>

<xsl:template match="$end-node">

<xsl:value-of select="."/>

new:end/

</xsl:template>

</xsl:stylesheet>

against the input

The brown fox jumped over the lazy dog.

El zorro marrón saltó el perro vago.

then I get the result

The brown xmlns:new="http://example.com/new"/>fox<new:end

xmlns:new="http://example.com/new"/> jumped over the lazy dog.

El zorro marrón saltóxmlns:new="http://example.com/new"/> el perro vago.

That looks as if the xsl:next-match for the template <xsl:template

match="$start-node" priority="5"> uses the template <xsl:template

match="$end-node"> which does not seem to make sense to me as the nodes

are different.

When I run the code online with http://www.exselt.net/demo I get the

result I want, namely

The brown xmlns:new="http://example.com/new"/>fox jumped over the lazy dog.

El zorro marrón saltóxmlns:new="http://example.com/new"/> el perro vago.

where the xsl:next-match uses the identity transformation template.

So this looks like a bug in Saxon 9.6 PE or I misunderstand the feature

to match on a variable reference.

Actions #1

Updated by Michael Kay about 10 years ago

  • Priority changed from Low to Normal

Added to W3C test suite as match-234

Actions #2

Updated by Michael Kay about 10 years ago

  • Status changed from New to In Progress

It seems to be a problem with binding references from variable references in a pattern to global variables. Binding is more dynamic in Saxon 9.6, as the first step towards support of packages, and it seems the context for this dynamic binding is not being set up propertly while evaluating a pattern.

Actions #3

Updated by Michael Kay about 10 years ago

The method Mode.searchRuleChain() (Mode.java line 612) correctly calls Rule.matches() to test whether a rule matches the current item; Rule.matches() sets up the binding context for cross-component references (eg global variable references) before calling Pattern.matches(). But the method Mode.searchRuleChain() (Mode.java line 758), which performs a filtered search in support of xsl:apply-imports and xsl:next-match, calls Pattern.matches() directly without going via Rule.matches(). (3 calls).

So what is happening is that patterns are being matched by next-match with the "current component" being the template containing the next-match instruction rather than the template to which the rule is attached; this means the wrong binding vector is being used, which results in the global variable reference getting the wrong value.

But changing this doesn't fix the problem....

Actions #4

Updated by Michael Kay about 10 years ago

The stylesheet looks wrong: the <apply-templates select="*, node()"/> processes all child elements twice, which can never produce the required output. I've changed it to <apply-templates select="node()"/> and after applying the above changes to Mode.java, the expected output is now produced.

Patch committed on the 9.6 branch. Not yet done for 9.7 as this area is in flux.

I've adjusted whitespace, namespaces, and accented characters to make the test more robust for W3C testing.

Actions #5

Updated by Michael Kay almost 10 years ago

  • Status changed from In Progress to Resolved

I have now applied the same patch to the 9.7 branch, and test match-234 now passes.

Actions #6

Updated by O'Neil Delpratt almost 10 years ago

  • % Done changed from 0 to 100
  • Fixed in version set to 9.6.0.4

Bug fix applied in the Saxon 9.6.0.4 maintenance release.

Actions #7

Updated by O'Neil Delpratt almost 10 years ago

  • Status changed from Resolved to Closed
Actions #8

Updated by O'Neil Delpratt about 9 years ago

  • Sprint/Milestone set to 9.6.0.4
  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release 9.6.0.4 added
Actions #9

Updated by O'Neil Delpratt about 9 years ago

  • Sprint/Milestone changed from 9.6.0.4 to 9.6.0.3
  • Fixed in Maintenance Release 9.6.0.3 added
  • Fixed in Maintenance Release deleted (9.6.0.4)
Actions #10

Updated by O'Neil Delpratt about 9 years ago

  • Sprint/Milestone changed from 9.6.0.3 to 9.6.0.4
  • Fixed in Maintenance Release 9.6.0.4 added
  • Fixed in Maintenance Release deleted (9.6.0.3)

Please register to edit this issue

Also available in: Atom PDF