Re: [xsl] Namespace Appearing for No Obvious Reason: What Could Cause It?

Subject: Re: [xsl] Namespace Appearing for No Obvious Reason: What Could Cause It?
From: "Martin Honnen martin.honnen@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 4 Mar 2015 17:44:55 -0000
Eliot Kimber ekimber@xxxxxxxxxxxx wrote:
I am generating HTML from a fairly complex transform made of many modules.
These modules declare a number of namespaces that apply to different
function packages, module-specific named templates and modes, etc., but
*not* to either the input elements or result elements (other than possible
an XHTML namespace). I have checked and all of these namespaces are
accounted for in the exclude-result-prefixes declarations for all the
modules involved.

In my transform I'm calling this template, which then applies the
following template:

<xsl:template name="generateMetaBrand">
   <xsl:apply-templates select="." mode="generateMetaBrand"/>
     </xsl:template>

     <xsl:template match="*" mode="generateMetaBrand">
   <meta name="brand" content="XXXX"/>
   <xsl:value-of select="$newline"/>
     </xsl:template>

The resulting element has an unwanted namespace declaration:


<meta xmlns:df="http://dita2indesign.org/dita/functions"; name="brand" content="XXXX"></meta>

The namespace in question is associated with functions and nothing else.
The namespace is only declared on <xsl:stylesheet> elements and the prefix
is not used on any start tag.

I can't think of anything that would cause this namespace, and only this
namespace (out of the several that are declared on each stylesheet), to be
output in the HTML.

What could cause this sort of rogue namespace declaration?

The normal explanation is that the namespace declaration is in scope for the literal result element, meaning it is declared on the xsl:stylesheet or xsl:transform of the stylesheet module and exclude-result-prefixes in that module does not list the prefix "df".


I realize you say that exclude-result-prefixes is present but if it really is, then it looks like a bug of the XSLT processor.

Current Thread