In article <H7************ *************** ***@comcast.com >,
Joe Kesselman <ke************ @comcast.netwro te:
Richard Tobin wrote:
I think this won't necessarily do quite the right thing in this case.
Despite its name, exclude-result-prefixes specifies a namespace uri to
be excluded, not a prefix. Since in this case he does need the
xinclude namespace, he may well still get a spurious xout prefix
declared somewhere.
In the implementation I'm familiar with (Xalan), it should do the right
thing, because it's take as a request not to issue any declarations for
prefixes bound to that URI except those which are actually used by an
element or attribute. But while that's a reasonable interpretation It
may not be the only one... Best suggestion I can make is to try it and
see what happens.
If it doesn't work -- well, an unused namespace declaration really is
pretty harmless.
I did indeed try this as a first move, and as Richard Tobin has said, it
did not suppress the declaration. (using Saxon) I can live with two
declarations of the namespace, its just not as neat as I'd hoped.
In fact, give that both namespaces are declared anyway in the output, I
found I can reverse the alias/output assignation:
<xsl:styleshe et xmlns:xsl="http ://www.w3.org/1999/XSL/Transform"
version="1.0" xmlns:x="http://www.w3.org/2001/XInclude"
xmlns:xi="myAli as">
..
..
..
<xi:include href="concat($M urPathRoot,$dis kpath,'/',xmlMur) "/>
and get, as output:
<configuratio n xmlns:x="http://www.w3.org/2001/XInclude"
xmlns:xi="http://www.w3.org/2001/XInclude">
..
..
..
..
<xi:include href="./endcapA/disk/2a/20302"/>
which leaves my end users looking at the familiar <xi:include .../>,
which I suspect they will be happier with.
thanks for the help
shaun