GNOME Bugzilla – Bug 317495
Too many items in a key within an exsl:node-set
Last modified: 2006-08-10 21:48:05 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.
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
Created attachment 53263 [details] Data file for testcase
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.
This looks complete but I haven't had time to look at it, maybe someone else will, Daniel
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
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.