RE: XSL & CDATA Processing

> 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