On 17/12/10 08:43, Johan Cwiklinski wrote:
> Hello,
[...]
> Here is our configuration:
[...]
> Hope that could help you :)
Thanks very much, that did it. It was unclear from the docs where you
put the name of the .jar file ("saxon9") and where you just put the name
"saxon".
One thing that switching to Saxon has done is reveal the holes in my
XSLT :-)
a. If a URI call to Cocoon to retrieve a web page through a Tidy
pipeline (to make it XML) returns an empty file (really null, not even
an empty root element), Xalan treats the statement
<xsl:variable name="foo" select="document($uri)"/>
as a non-event, and $foo is unset (that is, a binary test for if="$foo"
returns false). Saxon, on the other hand, emits a Java error message
about a null pointer; technically correct, except that it makes it
untestable because the error occurs before the document() call
completes, so its status is inaccessible in the XSLT.
b. Any ambiguity in template selection (normally a recoverable warning
if you run Saxon from the command line) returns the "Ambiguous..."
message as an error. Is this configurable? (ie get Saxon to not pass an
error status to Cocoon, but just log a warning, and continue recoverably
as it does in commandline mode?).
Obviously writing better XSLT is the answer...I should have paid closer
attention to Mike and Jeni's sessions on testing at the XML Summerschool...
///Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
