Continuing the saga of the "xalan" namespace prefix, Peter Janker
writes:
>In the generated script the 'xalan' prefix is needed because of the
>nodeset extension, but in the generating script it is simply a string
>and will therefor not be replaced (as is with the 'xsl:vendor'
>problem in the example).
Good point. XSLT is mainly concerned with ensuring that namespace
declarations exist for prefixes that are needed in the result, but it
copies any it finds that are not otherwise explainable nor excluded.
As I indicated before, the "xalan" prefix is considered otherwise
explainable, because its namespace is for elements that are
instructions to Xalan.
So you need to use the techniques for causing a namespace-decl to
appear on output. I think you should favor the one presented by Joe
Kesselman. I normally tell people to produce a junk attribute, but
if it were in the Xalan-specific namespace, Xalan would probably
try to interpret it. (Summary of the junk-attribute technique: on
some high-level element, hang z:junk="junk" and xmlns:z="whatever",
where the latter is what you really care about forcing onto the
output. The former forces it. You can see how use of Xalan's
namespace messes up this technique.)
The second issue, getting the correct prefix so that the argument in
system-property('xsl:vendor') will be in the XSLT namespace, is a
case where you need to know which prefix will be associated with the
XSLT namespace. What I wrote before applies here, as do Joe's laments
about the mismatch between the need to control the prefix and the
tools available to do so.
.................David Marston
