GNOME Bugzilla – Bug 165560
exclude-result-prefixes alters the qualified name of an element
Last modified: 2021-07-05 11:00:13 UTC
Please describe the problem: Here's a detailed description of the problem I sent to xsl-list, (when I wasn't sure if this was a misunderstanding of the specification or a bug in the implementation). I'll follow up with a response that confirms it as a bug. From: Carl Worth <cworth@cworth.org> Subject: [xsl] Can exclude-result-prefixes alter the qualified name of an element? To: xsl-list@lists.mulberrytech.com Date: Fri, 28 Jan 2005 14:56:25 -0500 Reply-To: xsl-list@lists.mulberrytech.com I've got an application in which the input tree (in namespace "input" say) is allowed to contain sub-trees to appear directly in the output tree (in namespace "output"). After the transformation, only nodes from the output namespace will appear in the result. As an example, I might have as input: <?xml version="1.0" ?> <i xmlns="input" xmlns:o="output"> <o:e/> </i> and desired output: <?xml version="1.0" ?> <o xmlns="output"> <e/> </o> The transformation I came up with is: <?xml version="1.0" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:i="input" xmlns:o="output" exclude-result-prefixes="i o" > <xsl:template match="i:i"> <o:o xmlns="output"> <xsl:apply-templates/> </o:o> </xsl:template> <xsl:template match="o:e"> <xsl:copy-of select="."/> </xsl:template> </xsl:stylesheet> An earlier version did not have the namespace declaration on the literal <o:o> element, nor did it have the exclude-result-prefixes attribute. That earlier version gave me a valid and correct result[*]: <?xml version="1.0"?> <o:o xmlns:o="output" xmlns:i="input"> <o:e/> </o:o> But this is not as clean as what I set out for originally. It's got an extraneous namespace declaration and unnecessary use of a prefix for what could be the default namespace. If I take the stylesheet as above, but using just a value of "o" for exclude-result-prefixes, I get quite close to the desired result: <?xml version="1.0"?> <o xmlns="output" xmlns:i="input"> <e/> </o> That's perfect except for one extraneous namespace declaration. And the XSLT specification explicitly says that getting rid of something like this is just what exclude-result-prefixes is designed for. But when I use exclude-result-prefixes="i o", (in other words, using the stylesheet exactly as quoted above), I get the following unexpected result: <?xml version="1.0"?> <o xmlns="output"> <e xmlns="input"/> </o> By simply excluding an unused namespace, the qualified name of the "e" element has changed(!) from a namespace of "output" to "input", the very namespace I was trying to exclude. Is this a bug in this implementation, or can someone explain to me how this behavior is justified by the specification? -Carl [*] All example output cited here was produced with xsltproc: $ xsltproc --version Using libxml 20616, libxslt 10111 and libexslt 809 xsltproc was compiled against libxml 20614, libxslt 10111 and libexslt 809 libxslt 10111 was compiled against libxml 20614 libexslt 809 was compiled against libxml 20614 [**] The following resources on namespaces were quite helpful: http://www.dpawson.co.uk/xsl/sect2/N5536.html#d6408e184 Particularly the explanations of namespace nodes and the behavior of copy-of with respect to namespace nodes. --~------------------------------------------------------------------ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/ or e-mail: <mailto:xsl-list-unsubscribe@lists.mulberrytech.com> Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
From: "Michael Kay" <mike@saxonica.com> Subject: RE: [xsl] Can exclude-result-prefixes alter the qualified name of an element? To: <xsl-list@lists.mulberrytech.com> Date: Fri, 28 Jan 2005 21:51:32 -0000 Reply-To: xsl-list@lists.mulberrytech.com The answer to your subject line is NO. ... The rules here are: (a) a literal result element copies all namespaces that are in scope in the stylesheet, except for excluded namespaces (the XSLT namespace and those listed in exclude-result-prefixes) (b) xsl:copy-of (in XSLT 1.0) copies all inscope namespaces from the source document, unconditionally. (c) In (a) and (b), copying a namespace means copying both the prefix and the URI. (d) Additional namespace declarations MAY be generated by the serializer (or in 2.0, the namespace fixup process) - the processor has some discretion in this. > > An earlier version did not have the namespace declaration on the > literal <o:o> element, nor did it have the exclude-result-prefixes > attribute. That earlier version gave me a valid and correct result[*]: > > <?xml version="1.0"?> > <o:o xmlns:o="output" xmlns:i="input"> > <o:e/> > </o:o> I don't think this is correct. In the input, the <o:e> element has an inscope namespace with prefix="", URI="input". This namespace node should have been copied, and there is nothing you can do in your stylesheet to prevent it. (XSLT 2.0 provides an option on xsl:copy-of). > > But this is not as clean as what I set out for originally. It's got an > extraneous namespace declaration and unnecessary use of a prefix for > what could be the default namespace. > > If I take the stylesheet as above, but using just a value of "o" for > exclude-result-prefixes, I get quite close to the desired result: > > <?xml version="1.0"?> > <o xmlns="output" xmlns:i="input"> > <e/> > </o> Again, I don't think this is correct. In the input, the <o:e> element has an inscope namespace with prefix="o", URI="output". This namespace node should have been copied, and there is nothing you can do in your stylesheet to prevent it. > > That's perfect except for one extraneous namespace declaration. And > the XSLT specification explicitly says that getting rid of something > like this is just what exclude-result-prefixes is designed for. But > when I use exclude-result-prefixes="i o", (in other words, using the > stylesheet exactly as quoted above), I get the following unexpected > result: > > <?xml version="1.0"?> > <o xmlns="output"> > <e xmlns="input"/> > </o> > The previous results looked non-conformant but liveable-with, this one looks disastrous. Michael Kay http://www.saxonica.com/
I just updated to the latest versions of libxslt and libxml2: $ xsltproc --version Using libxml 20617, libxslt 10112 and libexslt 810 xsltproc was compiled against libxml 20615, libxslt 10112 and libexslt 810 libxslt 10112 was compiled against libxml 20615 libexslt 810 was compiled against libxml 20615 and confirmed that the behavior with respect to these tests is identical.
okay, thanks ! Daniel
I would agree the latest release of xsltproc is not correct. I found and fixed a problem (libxslt/namespaces.c), and I believe the result is now okay, according to Kay's above comments:- bill@billsuper bug165560 $ xsltproc bug.xsl bug.xml bug.xsl:8: parser warning : xmlns: URI output is not absolute <o:o xmlns="output"> ^ bug.xml:2: parser warning : xmlns: URI input is not absolute <i xmlns="input" xmlns:o="output"> ^ <?xml version="1.0"?> <o xmlns="output"> <o:e xmlns="input" xmlns:o="output"/> </o> If you agree, we can close the bug. Bill
With the refactored code of Libxml2 the result is: <?xml version="1.0"?> <o:o xmlns:o="urn:test:output"> <o:e xmlns="urn:test:input"/> </o:o>
Mark this bug as fixed when we switch to the refactored code paths.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxslt/-/issues/ Thank you for your understanding and your help.