GNOME Bugzilla – Bug 150309
Regression caused by fix for 142768
Last modified: 2006-07-14 16:21:41 UTC
The fix checked in for 142768 causes a very strange regression in some cases where you are using xsl:import and default namespaces. Consider the attached test case. The correct behavior is to output > xsltproc test.xsl doc.xml <?xml version="1.0"?> <outer xmlns="urn:namespace:b" xmlns:a="urn:namespace:a"> <a:tag1/><a:tag2 xmlns="urn:namespace:a"/> </outer> Note that both tag1 and tag2 are in urn:namespace:a. This was the behavior exhibited by xsltproc 1.1.7. In 1.1.8 (and current CVS HEAD), however: >xsltproc test.xsl doc.xml <?xml version="1.0"?> <outer xmlns="urn:namespace:b" xmlns:a="urn:namespace:a"> <tag1/><tag2 xmlns="urn:namespace:a"/> </outer> tag1 is now incorrectly places in the urn:namespace:b namespace. The odd thing is that the only difference between the outputting of tag1 and tag2 is that tag1 is done inside an xsl:if!! Very strange.
Created attachment 30617 [details] Test input file
Created attachment 30618 [details] Inner (imported) XSL file
Created attachment 30619 [details] Outer XSL file
Without looking into the code changes, I ran your test using current CVS HEAD and got the following: bill@bbrack bug150309 $ xsltproc test.xsl doc.xml <?xml version="1.0"?> <outer xmlns="urn:namespace:b" xmlns:a="urn:namespace:a"> <a:tag1/><a:tag2 xmlns="urn:namespace:a"/> </outer> which seems to be the behaviour that you are expecting. Could you reconfirm the problem (making sure of libraries and versions, etc.) for me? Thanks, Bill
I did a fresh checkout this morning and I'm still seeing the bug. >/usr/local/bin/xsltproc --version Using libxml 20611, libxslt 10108 and libexslt 806 xsltproc was compiled against libxml 20611, libxslt 10108 and libexslt 806 libxslt 10108 was compiled against libxml 20611 libexslt 806 was compiled against libxml 20611
Like William, it seems my statically compiled version of xsltproc built from fully up2date CVS checkout generate the right thing: paphio:~ -> XSLT/xsltproc/xsltproc --version Using libxml 20611, libxslt 10108 and libexslt 806 xsltproc was compiled against libxml 20611, libxslt 10108 and libexslt 806 libxslt 10108 was compiled against libxml 20611 libexslt 806 was compiled against libxml 20611 paphio:~ -> ldd XSLT/xsltproc/xsltproc libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb75ca000) libz.so.1 => /usr/lib/libz.so.1 (0xb75bc000) libm.so.6 => /lib/tls/libm.so.6 (0xb759a000) libc.so.6 => /lib/tls/libc.so.6 (0xb7462000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000) paphio:~ -> XSLT/xsltproc/xsltproc test.xsl doc.xml <?xml version="1.0"?> <outer xmlns="urn:namespace:b" xmlns:a="urn:namespace:a"> <a:tag1/><a:tag2 xmlns="urn:namespace:a"/> </outer> paphio:~ -> Can you triple check your shared libraries ? Daniel
Thanks for the prompt response. I'm afraid I wasn't really clear in my previous note - as you know, libxslt is heavily integrated with libxml2, so it's quite important to assure both libraries are brought up to the latest CVS version. If I run with the libxml2-2.6.11 release and CVS version of libxslt I get the symptom you describe. However, when I use the CVS HEAD versions of both libraries the problem is not present. Could you check that both libraries are using the latest versions (and, simultaneously, I'll look further into why this happens :-\)? Thanks again for your help. Bill
Ahh, you are quite correct. With the CVS version of libxml2 the problem goes away. Narrowing it down a bit, the checkin to libxml2 that corrects the problem is r1.31 of SAX2.c
OK - most of r1.31 was adding some additional checks for out of memory conditions; the thing which must have cured the problem was a small discovery uncovered during debugging the OOM - at around line 2140 a new check was put in to assure that if the namespace prefix was NULL (i.e. using the [new] default namespace) the search was done using the URI instead of using the [old] default. I'm closing this bug report, with a note for anyone searching for this symptom that the correction is to use a version of libxml2 greater than 2.6.11. Thanks again for your help. Bill
This should be fixed in release libxslt-1.1.9. thanks, Daniel
This seems to be happening again with the latest CVS sources. I'll try to track it down further.
Results from some processors: Libxml2 (current result, not committed yet): <outer xmlns="urn:namespace:b" xmlns:a="urn:namespace:a"> <tag1 xmlns="urn:namespace:a"/><tag2 xmlns="urn:namespace:a"/> </outer> Except for the missing text nodes, this looks OK now. Saxon: <outer xmlns:a="urn:namespace:a" xmlns="urn:namespace:b"> <tag1 xmlns="urn:namespace:a"/> <tag2 xmlns="urn:namespace:a"/> </outer> MS .NET: <outer xmlns:a="urn:namespace:a" xmlns="urn:namespace:b"> <tag1 xmlns="urn:namespace:a"/> <tag2 xmlns="urn:namespace:a"/> </outer>
Fixed in CVS now.