Saxon

Legacy ID: #3648716 Legacy Poster: Michael Kay (mhkay)

It looks as if XmlUnit is asking for the result to be supplied as a DOM. Saxon supports this, but only if saxon8-dom.jar is on the classpath. (The reason for this awkwardness is that it was necessary to separate the DOM support because of DOM incompatibilities introduced in JAXP 1.5). Michael Kay

Legacy ID: #3649156 Legacy Poster: dumbdare (dumbdare)

Hi Michael, thanks for that pointer has sorted out the problem. The issue I now have is that the getResultDocument on the XmlUnit transformer object returns null after (supposedly) running the transform. The transformer is really just a wrapper around JAXP, the input xml file and xslt stylesheet are set as StreamSources in the constructor. Now the XmlUnit getResultDocument method actually calls the transform on the transformer class in javax (though this is mapped to Saxon) and then returns the getNode() value from the resultant DOMResult object. It's this that returns a null value. Now here's the crunch, I'm using the xsl:result-document in place of xalans redirect in my transforms to output the result to different files but this fails to create the files in the tests and, I'm guessing it won't create a DOMResult tree either which is why I get the null value when calling getNode(). So does Saxon have a similar extension to xalan:redirect? I've not found anything in the documentation and so assume I need to use the XSLT 2.0 function. Any idea why the behaviour is so different? Again any pointers would be most gratefully received... Rick

Legacy ID: #3649181 Legacy Poster: Michael Kay (mhkay)

You're in the area where there's a mismatch between the JAXP API, which only supports XSLT 1.0, and the facilities of XSLT 2.0 such as xsl:result-document. The rules for when a transformation creates an empty "principal result document" (the DOMResult), and when it doesn't create a result document at all, are pretty subtle. It's certainly possible that if all your transformation output does to xsl:result-document then the principal DOMResult will contain a null node at the end. You'll almost certainly find that the xsl:result-document files were written somewhere, but not necessarily where you expected. It might help to use absolute URIs in the href attribute. The answer to the question, does Saxon have a similar extension to xalan:redirect, is that it has xsl:result-document. Similar, but not identical. You can send the xsl:result-document output to any kind of destination you like, e.g. a DOMResult, by plugging in your own OutputURIResolver. Michael Kay

Legacy ID: #3649236 Legacy Poster: dumbdare (dumbdare)

BINGO! You were correct in assuming that the transforms had run correctly and output the files somewhere. It would appear that the treatment of relative paths is different, xalan appears to take paths relative to the input xml document whereas xsl:result-document was in fact taking the path relative to the working directory of my eclipse installation (from which I was running the unit tests). I do redirect all my output to seperate files so it would seem that the principal DOMResult does result in a null node. Well thanks for your help, has been an interesting and at times frustrating afternoon! Rick Edwards