Frequently Asked Questions

'Saxonce...Permission Denied' Error?

This kind of error message is most likely to occur when you're trying to run Saxon-CE from your local file-system rather than an HTTP server. The cause is that browsers run JavaScript on the file-system in a 'lockdown' mode, to prevent any malicious code running against unprotected files. It's advised that you leave your browser security settings intact and instead set up a light-weight HTTP sever on your own machine. (Some operating systems, such as Windows, come with a built-in HTTP sever that needs to be enabled first - this may also need permissions changes to let you copy files to it more easily).

Call from XSLT to JavaScript function has no effect?

One of the key principles in XSLT is that there are no 'side-effects', this is why variables are immutable. Because XSLT is 'side-effect free' processors, like Saxon-CE, can optimise code so that instructions whose output is unused by subsequent instructions can be optimized out. In this case, however, the side-effect is required for some other purpose - perhaps to change the scroll position of the HTML document. To ensure this function is executed it should be enclosed in an instruction such as xsl:sequence that adds items to the result tree.

I've changed the XSLT code, but I still get the same output as before?

This is most likely a browser-caching issue, make sure you're using the right method to clear the cache for the particular browser you're using. With Chrome and IE, the F5 button will work, though Ctrl-F5 is sometimes needed. Sometimes you need to perform the refresh operation more than once, because the cache is updated on the first refresh, but the rendered page still uses

Improving and measuring performance

Firstly, absolute performance isn't necessarily the top priority with user interfaces whether working in XSLT, JavaScript or any other programming language - its the perception of performance. Some desktop applications take ages to load but so long as they provide some progress indication, the wait doesn't seem too bad - the issue occurs when nothing at all appears to happen except for a 'wait' cursor appear.

So, with Saxon-CE, if you can use xsl:schedule-action to either gradually build a display or animate a progress indicator this will probably go a long way to improving both the perception and the usability of the website.

Be aware also that console logging (which only affects the Debug Saxonce variant) has a big impact on performance itself, so if you've got lots of xsl:message instructions within xslt iterations, try trimming these down a bit. Also, compare performance with and without the logLevel set.

When performing a transform, the XML data source (which tends not to be cached on the browser) is downloaded asynchronously while the XSLT (which can be cached for longer) can be downloaded and compiled synchronously.

More on file caching: You should be able to set up your web server to instruct browsers how to cache specific file types to improve performance, while still ensuring that when you update your XSLT that the change is immediate. Google uses a small 'boot' script with a .nocache.js extension that is cached for a limited time, but this then loads the much larger .js files that may be cached for much longer - a similar strategy could be used with a small 'boot' XSLT which uses xsl:include.

One method to measure performance is to place 'marker' xsl:message instructions within the XSLT - all such messages recording timing information that can be exploited by web developer tools. The following screenshot shows the Chrome browser timeline - xsl:message outputs show up as vertical bars in the timeline, Saxon-CE also adds time markers for key events like when compiling begins and ends. To use this feature, the logLevel in Saxon-CE should be set to FINE. For Chrome, you need to bring up the Developer Window (F12), switch to the Timeline view and press a 'Record' button (not easy to spot) to start recording events - a screenshot is shown below: