-
mhkay committed revision 457 to the Saxon XSLT and XQuery Processor SVN repository, changing 2 files.
2009-11-24 10:23:00 UTC in Saxon XSLT and XQuery Processor
-
Saxon-EE sometimes optimizes a call to a user-defined function by inlining the function body (that is, replacing the function call with the body of the called function.) It is possible for this to be done before the called function is type-checked. When this happens (which will typically be when the call is a forwards reference), any code that is needed to convert the result of the called...
2009-11-24 09:47:25 UTC in Saxon XSLT and XQuery Processor
-
First, please note that I ask people to submit support requests on the saxon-help mailing list or forum, not in this tracker. That is so that users can find genuine confirmed bugs more easily.
This is not a bug. The rules for string-to-double conversion are strictly laid down in the XSLT/XQuery/XPath specifications, and they do not allow commas as thousands separators. I would suggest using...
2009-11-24 00:47:32 UTC in Saxon XSLT and XQuery Processor
-
I don't think many Saxon users monitor this forum; you're probably more likely to get a reply if you ask on the saxon-help mailing list (you need to subscribe first).
2009-11-19 20:35:31 UTC in Saxon XSLT and XQuery Processor
-
I think the two most useful bits of advice I can give for this scenario are
(a) make sure you cache and reuse the compiled stylesheet (JAXP Templates object or s9api XsltExecutable)
(b) think about how you will measure performance, both at the overall system/application level and the XSLT contribution. If you put good instrumentation into place, it will be much much easier to do...
2009-11-18 14:06:50 UTC in Saxon XSLT and XQuery Processor
-
You seem to have misunderstood the specification of the translate() function. When you write translate(name(),'_x002F_',' '), the effect is to replace any occurrence of the characters underscore, x, 0, 2, or F by a single space.
I've no idea what you thought this function call would do, so I can't really advise on how to rewrite it. I suspect you need to use the replace() function.
Please...
2009-11-17 09:54:06 UTC in Saxon XSLT and XQuery Processor
-
This is what I get with 9.1.0.5 (and all other releases):
Saxon 9.1.0.5J from Saxonica
Java version 1.6.0_17
Warning: at xsl:transform on line 26 column 138 of spl.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Warning: on line 88 of spl-common.xsl:
The attribute axis starting at a document node will never select anything
Warning: on line...
2009-11-16 20:02:19 UTC in Saxon XSLT and XQuery Processor
-
I haven't managed to replicate the problem with sum(). How did you get it?.
2009-11-16 19:45:58 UTC in Saxon XSLT and XQuery Processor
-
I've taken the opportunity to improve the diagnostics for the condition. It turns out the location (line number / module) of the instruction that generated the most recent startElement event is available at the time the error is detected, which means it's not difficult to add to the message "Most recent element start tag was output at line 1213 of module spl-common.xsl". In some cases this will...
2009-11-16 19:18:02 UTC in Saxon XSLT and XQuery Processor
-
Thanks for sending the repro.
Saxon 6.5 reports numerous instances of "Recoverable error
at xsl:attribute on line 803 of file:/e:/users/lee/Stylesheet/spl-common.xsl:
Cannot write an attribute node when no element start tag is open"
In XSLT 1.0 this was a recoverable error, and the recovery action was to ignore the attribute (it simply wasn't written). (Processors have the option to...
2009-11-16 18:46:53 UTC in Saxon XSLT and XQuery Processor
