GNOME Bugzilla – Bug 684564
Regression: Default namespace not correctly used
Last modified: 2012-11-21 09:44:04 UTC
As of libxslt 1.1.27 the default namespace is no longer honored when creating elements with a dynamic name (using { }). See the following XSLT: ----------------------------------------------------------------------------- <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="my::namespace"> <xsl:variable name="var">baz</xsl:variable> <xsl:output indent="yes"/> <xsl:template match="/"> <root> <!-- This is in the correct namespace "my::namespace" --> <foo>...</foo> <!-- OK. --> <xsl:element name="bar">...</xsl:element> <!-- Still okay. --> <!-- Wrong! These are without namespace. --> <xsl:element name="{concat('foo', 'bar')}">...</xsl:element> <xsl:element name="{$var}">...</xsl:element> <xsl:element name="{local-name(*)}">...</xsl:element> <!-- Explicitly setting the namespace fixes this. --> <xsl:element name="{$var}" namespace="my::namespace">...</xsl:element> </root> </xsl:template> </xsl:stylesheet> ----------------------------------------------------------------------------- Output of libxslt 1.1.27 (wrong): No namespace (xmlns="") is set for elements with a dynamic name ("foobar", "baz", "stylesheet"). Elements with static names (elements "root", "foo", "bar") are in the default namespace as expected. Explicitly setting the namespace (element "baz") works as well. /tmp/libxml> libxslt-1.1.27/xsltproc/xsltproc /tmp/test.xsl /tmp/test.xsl <?xml version="1.0"?> <root xmlns="my::namespace"> <foo>...</foo> <bar>...</bar> <foobar xmlns="">...</foobar> <baz xmlns="">...</baz> <stylesheet xmlns="">...</stylesheet> <baz>...</baz> </root> ----------------------------------------------------------------------------- Output of libxslt 1.1.26: Good! All elements belong to the default namespace. /tmp/libxml> libxslt-1.1.26/xsltproc/xsltproc /tmp/test.xsl /tmp/test.xsl <?xml version="1.0"?> <root xmlns="my::namespace"> <foo>...</foo> <bar>...</bar> <foobar>...</foobar> <baz>...</baz> <stylesheet>...</stylesheet> <baz>...</baz> </root> ----------------------------------------------------------------------------- The spec reads (http://www.w3.org/TR/xslt#section-Creating-Elements-with-xsl:element): If the namespace attribute is not present then the QName is expanded into an expanded-name using the namespace declarations in effect for the xsl:element element, including any default namespace declaration.
As an additional indication that the "old" behaviour was correct, Saxon gives the same results as libxslt did in 1.1.26, e.g. with the xslt above and the following command line: java -jar saxon.jar test.xsl test.xsl
Created attachment 225355 [details] [review] Patch Oops, my bad. Here's the fix.
Thanks, the patch works for me.
I can confirm that the patch restores the "old" behaviour. Thanks for the quick fix!
Thanks Nick ! Applied and pushed: http://git.gnome.org/browse/libxslt/commit/?id=be264bd3034b352a7c768ba62bf62cca22d074d9 Daniel
Hi all, this bug, which is present in the latest release - libxslt-1.1.27-2.mga3.src.rpm - has broke the test suite of XML-Grammar-Fiction: http://www.shlomifish.org/open-source/projects/XML-Grammar/Fiction/ . While in the source distribution, «xsltproc extradata/fiction-xml-to-html.xslt t/fiction/data/xml/sections-and-paras.xml» yields empty «xmlns=""» with the Mageia-shipped xsltproc and libxslt, then with the git master HEAD version of libxslt, or with «java org.apache.xalan.xslt.Process -IN t/fiction/data/xml/sections-and-paras.xml -XSL extradata/fiction-xml-to-html.xslt», I am not getting those. The erroneous libxslt/xsltproc behaviour confuses my test suite and makes it fail. Would it be possible to make a new release of libxslt soon with these fixes and other fixes? Please? “Release early, release often.” Regards, -- Shlomi Fish
(In reply to comment #6) > Hi all, > > this bug, which is present in the latest release - > libxslt-1.1.27-2.mga3.src.rpm - has broke the test suite of > XML-Grammar-Fiction: > http://www.shlomifish.org/open-source/projects/XML-Grammar/Fiction/ . While in > the source distribution, «xsltproc extradata/fiction-xml-to-html.xslt > t/fiction/data/xml/sections-and-paras.xml» yields empty «xmlns=""» with the > Mageia-shipped xsltproc and libxslt, then with the git master HEAD version of > libxslt, or with «java org.apache.xalan.xslt.Process -IN > t/fiction/data/xml/sections-and-paras.xml -XSL > extradata/fiction-xml-to-html.xslt», I am not getting those. The erroneous > libxslt/xsltproc behaviour confuses my test suite and makes it fail. > > Would it be possible to make a new release of libxslt soon with these fixes and > other fixes? Please? “Release early, release often.” > > Regards, > > -- Shlomi Fish Anyone? Regards, -- Shlomi Fish
I'd recommend opening a bug with mageia and try to see if they can roll the patch for this issue in the next alpha or beta release of mg3.
(In reply to comment #8) > I'd recommend opening a bug with mageia and try to see if they can roll the > patch for this issue in the next alpha or beta release of mg3. This is hardly a good solution because: 1. It means more work for the downstream packagers (of each individual distribution) during both the maintenance of the existing package, and when the new package is released with a fix. Furthermore, this fix needs to be applied in each and every downstream distribution. 2. It does not help those who use libxslt packages that do not contain the fix, which will need to investigate on their own (as I did). 3. The status of this bug as "RESOLVED FIXED" is misleading, because while it was fixed in the git repository, it is still not available in a normal, published, release, which is what most people use. If I were the libxslt maintainer, I would not mark this bug as RESOLVED before I made the release. I recall a "Newsforge" essay titled the "CVS excuse", which criticised the fact that people kept responding to problems reported in the latest release with "it is already fixed in the CVS", which is not really a good excuse. 4. Some people (like me) will bother the forums and bug trackers with duplicate reports of the same problems. See the first item here: http://www.joelonsoftware.com/articles/customerservice.html ------------------ In short, while I as a Magiea packager can and will incorporate the patch into the Mageia package, the upstream libxslt developers should still promptly make a new stable release. Regards, -- Shlomi Fish
libxslt-1.1.28 is released it includes the fix, Daniel