After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 317495 - Too many items in a key within an exsl:node-set
Too many items in a key within an exsl:node-set
Status: RESOLVED FIXED
Product: libxslt
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2005-09-29 09:58 UTC by Phil Endecott
Modified: 2006-08-10 21:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase Stylesheet (1.52 KB, application/xml)
2005-10-09 20:51 UTC, Phil Endecott
Details
Data file for testcase (44 bytes, text/xml)
2005-10-09 20:52 UTC, Phil Endecott
Details

Description Phil Endecott 2005-09-29 09:58:43 UTC
I find that a key() expression returns more nodes than it should.  The
expression is evaluated in the context of an exsl:node-set document.  The code
uses the same key with multiple exsl:node-set documents.

See my bug #148773 from about a year ago.  I got your fix for that from CVS and
had been using that version until yesterday when I upgraded to version 1.1.15
(Debian) and found this new issue.  I have just tried with the current CVS
version and it also fails.  So the regression occured between 2004-08-02 and 1.1.15.

I am still working on a minimal test case and will post something here when it
is narrowed down further, but for the time being here is an overview.  I am
hoping that perhaps you will immediately recognise the problem from this
description.

I have a key definition:

<xsl:key name="tree-by-subject_id" match="tree" use="@subject_id"/>

I perform transformations in a series of steps, using exsl:node-set and
variables to store the intermediate results:

<xsl:variable name="X">
  <xsl:apply-templates select="/" mode="step1"/>
</xsl:variable>

<xsl:variable name="Y">
  <xsl:apply-templates select="exsl:node-set($X)" mode="step2"/>
</xsl:variable>

<xsl:apply-templates select="exsl:node-set($Y)" mode="step3"/>


More than one of these steps makes use of the key in expressions like this:

<xsl:value-of select="count(key('tree-by-subject-id',$a))"/>

Generally the result will be 1, i.e. each subject_id attribute value will
identify a single tree node; this code is checking for duplicates.

With the new version of libxslt I find that this code is returning 2 in most
cases during one of the transformation steps.

If instead I write

<xsl:value-of select="count(//tree[@subject_id=$a])"/>

I still get 1 as before (but it evaluates more slowly).

I consider the fact that the key() expression returns a different result from
the //tree[] expression, which is just the key definition inlined, to be the
"smoking gun" that this is a library bug.

Looking at

<xsl:for-each select="key(...)">
  <xsl:value-of select="generate-id()">
</xsl:for-each>

and

<xsl:for-each select="//tree[...]">
  <xsl:value-of select="generate-id()">
</xsl:for-each>

I see that the key() returns the same node as the inline version of the
expression, plus one other node.

I will continue to work on a minimal example.

I have also upgraded libxml2, if that matters.

Regards,  --Phil.
Comment 1 Phil Endecott 2005-10-09 20:51:41 UTC
Created attachment 53262 [details]
Testcase Stylesheet

Here is a fairly minimal testcase to illustrate this bug.

$ xsltproc --version
Using libxml 20622, libxslt 10115-CVS1030 and libexslt 812-CVS1030
xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812
libxslt 10115 was compiled against libxml 20622
libexslt 812 was compiled against libxml 20622

$ xsltproc test.xslt test.xml
using keys: 2 5 id2243519 5 id2243512
not using keys: 1 5 id2243519
Comment 2 Phil Endecott 2005-10-09 20:52:15 UTC
Created attachment 53263 [details]
Data file for testcase
Comment 3 Phil Endecott 2005-10-17 22:09:10 UTC
Has anyone been able to look at this yet?
Let me know if you need more explanation about the test case, or if there is
anything else I can do.

--Phil.
Comment 4 Daniel Veillard 2005-10-18 19:26:10 UTC
This looks complete but I haven't had time to look at it, maybe someone else will,

Daniel
Comment 5 kbuchcik 2006-08-10 13:58:18 UTC
I don't know when/if you issue was fixed (completely fixed?),
but with the current CVS HEAD I get the following correct result:

>xsltproc bug317495.xsl bug317495.xml
using keys: 1 5 id62109
not using keys: 1 5 id62109
Comment 6 Phil Endecott 2006-08-10 21:48:05 UTC
Thanks for looking at this.

I gave up hoping for a fix in about January and now use a different XSLT tool
which doesn't have this bug.  I'm therefore not in a position to verify that it
is fixed.  But the output that you presented looks right.

Phil.