using XX compiler in saxon-js (xslt3)

Added by Alasdair Hurst about 2 years ago

Hi there, we're using the a combination of the xslt3 command line and the saxon-js module to allow users to provide two inputs (template and data) and execute an XSLT transformation programmatically.

Up until now, we've been wrapping the xslt3 command line module in nodejs to take the tempalte and generate a sef file, then read this into memory, but i'm sure there must be a better way of doing this since I understand that the xslt3 command line wraps the saxon-js module, so all functionality should be available directly in that package? We then use SaxonJS.transform to use the sef file (stylesheetText).

I can't seem to find documentation for the full saxon-js API though, and it's not permitted to un-minify the source code, so could someone provide some help to point out the saxon-js APIs I need to use to replace a call to xslt3 and generate a compiled stylesheetText/sef entirely in-memory?

The command we want to replace is the following:

xslt3 -xsl:file.xsl -export:sef.json -nogo

Replies (3)

Please register to reply

RE: using XX compiler in saxon-js (xslt3) - Added by Michael Kay about 2 years ago

You should find everything you need at!api

As stated at!starting/export/compiling-using-XX

*Using the JavaScript API

There is no published API available at this release for compiling stylesheets using the XX compiler. This should be done using the command-line interface. *

You're right that the XX compiler code is there in the SaxonJS module; but the incantations needed to invoke it are complex and therefore unpublished at this point. And we can't simply tell you what the magic incantations are, because all the names of properties and methods in non-public APIs get mangled by the Closure compiler. We need to design an API for this.

RE: using XX compiler in saxon-js (xslt3) - Added by Alasdair Hurst about 2 years ago

Thanks for the quick reply. Is there any plans to release a public API?

We will keep using the CLI for now, although there are a few teething problems consuming it this way since for example, we have to parse the syntax errors from stderror output into a consumable message to provide back to clients, removing the extra "internal" information like the file path.

Additionally, the error format has sometimes changed from release to release which leaves us to either pin the version of the module and not get updates straight away, or breaks our error parsing when a new version is published.

Would be great if there were any additional quality improvements to help with this use-case in future releases!

RE: using XX compiler in saxon-js (xslt3) - Added by Michael Kay about 2 years ago

Indeed, designing the error reporting part of the API is a significant part of the challenge, especially as errors originate both in the Javascript and XSLT parts of the compiler.

This is on the shopping list for SaxonJS 3; we haven't yet decided what will be included (let alone when the release will be).


    Please register to reply