Re: [xslt] xsl:key, key() [+current()]- LibXSLT disagrees with fellow processors [vol.2]
- From: Jan Pokorný <jpokorny redhat com>
- To: The Gnome XSLT library mailing-list <xslt gnome org>
- Subject: Re: [xslt] xsl:key, key() [+current()]- LibXSLT disagrees with fellow processors [vol.2]
- Date: Fri, 13 Dec 2013 16:04:18 +0100
Hello Nick,
On 13/12/13 14:36 +0100, Nick Wellnhofer wrote:
On 13/12/2013 00:53, Jan Pokorný wrote:
first, there's a references recap I found for this topic:
- original mail I've borrowed the subject from [1]
- bugzilla.gnome.org bug [2]
- thread on xsl-list ML [3], which may explain why Saxon behaves as it
does (and hence differs from current behavior of libxslt in this
aspect)
This is a long-standing bug in libxslt. I just fixed it with commit
ce5a0dd6:
https://git.gnome.org/browse/libxslt/commit/?id=ce5a0dd6a70efdb214aba12fefc6bbf8c201b838
Thanks for confirmation and for the bugfix itself, indeed (so yeah,
as context node for "match" being set at both ctxt and xpctxt, the
same needs to be done for "use"). I can confirm the fix also passed my
testcase. As an aside, in the commit link, I've noticed that there
seems to be tabs to spaces conversion in progress.
Another think I've noticed is that currently the master has the
problem with bug-182 in the test suite (which was the case also prior
to this recent commit). Interestingly, my system-wide copy of
xsltproc (libxslt-1.1.28-1.fc18.x86_64) does not produce a correct
result either:
<?xml version="1.0"?>
<body><p>text()[2]: text 1 </p><p>b[2]: b 2 </p></body>
I could not find any reference in Gnome Bugzilla, should I file a new
bug for this?
--
Jan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]