David Carlisle
So that reads to me like exclude-result-prefixes will
work for an XSL transform that copies nodes in the
XHTML namespace from input to output, but might
monkey-wrench a transform of nodes in the null
namespace to nodes in the XHTML namespace. Is that
correct?
No, exclude-result-prefixes never gives the system licence to change the
namespace of an element or attribute. It only stops namespace nodes being
copied to the result tree because they happen to be in scope from somewher
higher in the stylesheet. Any element that's in a namespace (or in no
namespace) so all elements and attributes will _always_ have whatever
namespace nodes needed to correctly interpret the name.
Such namespace nodes may produce namespace declarations in the serialisation
irrespective of whether that namespace is specified with exclude result
prefixes.
The XSLT 1 situation is that with a bit of care you have absolute control
over what namespace nodes are in the result tree.
so for example if you want a namespace node mapping "" (default namespace)
to http://www.w3.org/1999/xhtml (XHTML) and "m" to
http://www.w3.org/1998/Math/MathML (MathML) then you can do that.
then the tree has elements in the xhtml or mathml namespaces and a system
can choose _any_ prefix it wants for those namespaces and add suitable
namespace declarations, however since it must have added namespace
declarations xmlns="http://www.w3.org/1999/xhtml"
xmlns:m="http://www.w3.org/1998/Math/MathML"
already, it would be peverse of the system not to use those prefixes.
In my experience most systems do use the prefixes specified in namespace
nodes in the result tree. I've had to try quite hard to get any system to
make up prefixes on the fly (the easiest way to force this is to copy
several attributes with the same prefix but different namespaces in to an
element, it has to rename all but one of the attributes to use new prefixes
on serialisation) |