Hi Christian,
Thank you for taking time to look into this!
• Similar to eXist, the BaseX DOM models are pretty different from Saxon’s representation. In BaseX, it is possible to ceate a standard Java DOM representation for arbitrary XML nodes, but I doubt that working it will be much faster than serializing nodes, because the latter option is usually very fast in BaseX.
OK, I understand. You're right, it probably wouldn't be faster. In any case, serializing/deserializing transformation input (typically small pages) is never going to be a bottleneck in a web context, so it doesn't matter. Xslt compilation on the other hand does incur a noticeable cost if it is repeated for each request.
Regards, Tom
On 6/02/2017 14:08, Christian Grün wrote:
Tom,
Thanks for the excellent summary on what could be done, very appreciated!
- basic XSLT caching with the existing JAXP interface, as described in the
articles or similar; 2. specific saxon:transform() etc. functions that use the new Saxon interface (and do caching); 3. idem but implemented for the regular xslt:transform(), or maybe the function in XQFO 3.1 (thanks for the link, I was not aware of this)?
Variant 1 is surely something that I can easily include. I will check out your links and give you some update this week.
Talking about a tighter integration, I fully agree with Adam’s comments:
• Switching to to the Saxon’s API would be a reasonable choice. We still have users who work with standard Xalan XSLT, but we could definitely use Michael Kay’s s9api whenever Saxon is found in the classpath. I have added an issue to our GitHub tracker [1].
• Similar to eXist, the BaseX DOM models are pretty different from Saxon’s representation. In BaseX, it is possible to ceate a standard Java DOM representation for arbitrary XML nodes, but I doubt that working it will be much faster than serializing nodes, because the latter option is usually very fast in BaseX.
Cheers, Christian
[1] https://github.com/BaseXdb/basex/issues/1408
Thinking forward, absolutely wonderful would be some form of tight integration with Saxon that passes nodes from BaseX to Saxon directly, without serializing/parsing.
Incidentally, there is an interesting note on this topic on the eXist developer platform (scroll to the bottom): https://github.com/eXist-db/exist/issues/791
But any of option 1-3 (or similar) would do the trick and be great!
Best regards, Tom
On 5/02/2017 15:01, Christian Grün wrote:
Hi Tom,
You are right. xslt:transform() does nothing else than sending stylesheets to the registered XSLT processor (which is usually Xalan or Saxon).
The XQFO 3.1 spec [1] will provide an fn:transform function that provides a "cache" option. As the definition of this function is very Saxon-specific, I am not sure if we will completely support it in future. For now, if you know how caching is enabled in Saxon, feel free to provide me with some example code, and I will see if I can easily embed it in our current architecture.
Cheers, Christian
[1] https://www.w3.org/TR/xpath-functions-31/#func-transform
On Sun, Feb 5, 2017 at 1:52 AM, Tom De Herdt tom.deherdt@skynet.be wrote:
Hi all,
I'm evaluating BaseX as an alternative (and very attractive) platform for an XML/XSLT-based website that needs to be migrated from ASP.NET.
The website relies heavily on XSLT. Each page is generated on-the-fly with Saxon.NET, using a complex set of stylesheets. To get reasonable performance, stylesheets are compiled on first use and cached for subsequent requests.
This is crucial, as XSLT compilation is typically orders of magnitude slower than execution; without caching, the server would spend most of the time compiling the same stylesheets over and over again.
I was happy to find that BaseX can use Saxon, but as far as I can see, xslt:transform() does not cache compiled stylesheets. Can anyone confirm this?
If not, are there any plans to support stylesheet caching in the future?
Or is there a way to reuse compiled stylesheets manually?
Thanks, Tom De Herdt