I have often gotten questions regarding the use of default namespaces in Xslt. It is really an XPath issue, but it becomes an issue as folks progress from using Xml data documents (which handles default namespaces nicely) to doing transforms. They want to minimize the impact of namespaces, and so use the same logic in the Xslt as in their data documents. However logical the thinking is, a common gotcha is to try to use a default namespace in XPath statements in an Xslt template.

It is a real gotcha that trips up folks getting started with transforms. Instead of using a namspace prefix for every node of every XPath statement, they think that a default namespace could make their lives easier. It is a logical conclusion. Given this Xml snip:

<BackgroundSearchPackage xmlns="http://ns.hr-xml.org">

<Screenings>this is the screenings element contentScreenings>

<AdditionalItems>this is the additional items element contentAdditionalItems>

BackgroundSearchPackage>

Stylesheet writers think they can get the value of the child elements by using the XPath:

<xsl:value-of select="BackgroundSearchPackage/ Screenings/ AdditionalItems"/>

This of course does not work because it does not have a namespace reference. When they add in a namespace prefix, it looks like this:

<xsl:value-of select="hrxml:BackgroundSearchPackage/ hrxml:Screenings/ hrxml:AdditionalItems"/>

However this seems awkward and unnecessarily repetitive. (An alternative would be an even more awkward syntax using "local-name()".) The logical conclusion is to define a default namespace in the Xslt and that would solve the repetitive prefix in all XPaths. While quite logical, this in fact does not work.

Indeed, Xslt 1.0 writers need to get used to the prefixes in their XPaths, because they are necessary for hitting the node correctly. The 2.0 of Xslt addresses this common gotcha.

6:06:48 PM    comment []