Bug #2219
closedxsl:next-match; patterns using match="$var" syntax
100%
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:apply-templates select="@* , node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="$start-node" priority="5">
</xsl:template>
<xsl:template match="$end-node">
<xsl:value-of select="."/>
</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.
Updated by Michael Kay about 10 years ago
- Priority changed from Low to Normal
Added to W3C test suite as match-234
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.
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....
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.
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.
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.
Updated by O'Neil Delpratt almost 10 years ago
- Status changed from Resolved to Closed
Updated by O'Neil Delpratt almost 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
Updated by O'Neil Delpratt almost 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)
Updated by O'Neil Delpratt almost 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