Frequently Asked Questions¶
'Saxonce...Permission Denied' Error?¶
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¶
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: