Problem with namespace-alias when source and dest namespaces the same

Hi,

I've run into a problem with Saxon 9.4.0.3j HE and namespace-alias when the source and destination namespaces are the same.

I have the following xslt.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="urn:mynamespace" xmlns:n="urn:mynamespace"> <xsl:namespace-alias result-prefix="#default" stylesheet-prefix="n"/>

<xsl:template match="/"> <n:cd> <n:title>Title</n:title> </n:cd> </xsl:template> </xsl:stylesheet>

I am expecting an output of

<title>Title</title>

Effectively stripping off the namespace prefix and moving elements to the default namespace

Instead, I get <n:cd xmlns="urn:mynamespace" xmlns:n="urn:mynamespace"> <n:title>Title</n:title> </n:cd>

This causes problems with the next piece of software that tries to read the output - as it isn't namespace aware and so can't handle the prefix.

Of course I can fix the xslt so it doesn't do this by removing all the n: prefixes and the namespace-alias element, but the map is being produced by MapForce, and I'm trying to minimise the amount of post processing required on it to make maintenance as easy as possible.

Is this a bug, or another example of where the xslt 1.0 spec is unclear how such a situation should be processed?

Regards,

Tim

Replies (1)

RE: Problem with namespace-alias when source and dest namespaces the same - Added by Michael Kay over 12 years ago

I think that technically, Saxon is behaving correctly here. XSLT 1.0 said nothing about what prefix should be used in the output, but XSLT 2.0 is prescriptive. It says this:

Where namespace aliasing changes the namespace URI part of the expanded QName containing the name of an element or attribute node, the namespace prefix in that expanded QName is replaced by the prefix indicated by the result-prefix attribute of the xsl:namespace-alias declaration.

In your case, namespace aliasing is not changing the namespace URI, and therefore under this rule it doen't change the prefix. I find it hard to imagine that anyone envisaged this use case when that rule was drawn up, but the rule nevertheless seems clear. It would be very easy to remove the line of code in Saxon that corresponds to this rule, but much harder to predict the consequences.

I think the bottom line is that the facility was designed for changing namespace URIs, not for changing prefixes, and if it doesn't work for the use case of changing prefixes, that's because it wasn't designed for that purpose.

(1-1/1)

Please register to reply

Project

Profile

Help

Saxon