Well, I am running this in a Java Application and
using the built in processor in JDK1.4.2 .
TransformerFactory factory =
TransformerFactory.newInstance();
Templates template =
factory.newTemplates(new StreamSource(
new FileInputStream(DUPLICATES_XSL)));
Transformer xformer = template.newTransformer();
Source source = new DOMSource(tempDocument);
DocumentBuilder builder=
DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document doc = builder.newDocument();
Result result = new DOMResult(doc);
xformer.transform(source, result);
I can't comment on why Xalan should produce the result it does, but I
suspect that you would get better results by not using a DOMSource. I think
it's true for most XSLT processors that they work best if you allow them to
build the tree themselves using their own native tree structure. Unless you
have a very good reason for using a DOM, use a SAXSource or StreamSource
when using JAXP.
I have tried using Saxon (again from within the Java
Application) and that generates a different warning
message
Warning: at copy on line 12 of :
Cannot write an attribute node when no element start
tag is open
Also, the output does not contain any of the
attributes for the Text tag.
This appears to be a previously unreported Saxon bug. The (very complex)
algorithm for sorting DOM nodes into document order, which is needed here
because of the union expression select="@*|node()", is not dealing correctly
with node-sets that contain a mixture of attribute and non-attribute nodes.
Walking through this in the debugger has reminded me quite how inefficient
the DOM is, compared with Saxon's native input tree. It's really best
avoided! (though I will of course fix the bug).
You can circumvent the problem (and save Saxon a lot of work) by writing
<xsl:apply-templates select="@*"/>
<xsl:apply-templates select="node()"/>
Scope here for an internal optimization!
Michael Kay