Triggering XSLT to run in the Browser: Saxon JS

[ebeshero]

This is for @NADGIT, who'd like to get XSLT running in the browser. The enlightened and current way to do that now is with SaxonJS, designed by the developers of the XSLT specs. http://www.saxonica.com/saxon-js/index.xml

Here's how it works: You prepare your XSLT to be run with Saxon JS locally in oXygen (where the latest Saxon parsers are available). You post it in your webspace. And we install SaxonJS on the newtfire web server following the instructions. It's designed for interactivity of the kind you want--and possibly even better--you might be able to control MORE of the interactivity with XSLT using SaxonJS.

There's a terrific starter pack to help make this easier, developed by a friend of ours, @wendellpiez, called XML JellySandwich: https://github.com/wendellpiez/XMLjellysandwich We can take a look at both! Happy to tinker with this.

@NADGIT I think we want to work with your original XSLT 3.0 file for this, so maybe let's restore that to the repo (or save it alongside your 1.0 version). Thanks to @djbpitt for pointing us in the right direction!

[NADGIT]

I'm very concerned that we will not have time to implement this. Unless JellySandwich is much faster to implement, I think I would prefer to work with SaxonJS. SaxonJS has a greater amount of documentation for me to use for debugging and programming. Also, from what I can tell, the SaxonJS API doesn't seem horribly complex. However, you would probably know better. What is your advice?

[NADGIT]

I was able to install the SaxonJS addon thanks to this handy dandy explanation https://www.youtube.com/watch?v=hxWJjRGQ3ls

[ebeshero]

@NADGIT Great! This is something I’ve been wanting to try, and I don’t think it will take terribly long—and certainly will be more satisfying and easier to debug than the old native browser interaction w XSLT. Saxon JS was designed for your implementation!

[NADGIT]

From what I've watched and researched, it does seem easier to use. I'm always willing to accept new tools, I'm just getting nervous seeing as we haven't got much time left in the semester. If worst comes to worst, I can still get the XSLT to work by having a different XSLT file for each location. So, are there any steps you need me to take on my end?

[ebeshero]

@NADGIT I think you're doing great so far! Don't be nervous--the documentation is clear and up to date, and I think you may have done the hard part with the oXygen add-on. And learning new things is what we're all about. Also, projects aren't due until Thursday of Finals Week (the week after the presentation), and if you get stuck I'm ready to jump in to help. I was expecting to have to do this first and show you how next week, but I suspect you'll get there ahead of me. (I was going to work on this on Friday evening / Saturday morning, which is when I come free again!)

We need the Saxon JS implementation in the browser--try installing it in your webspace (and/or Bloodborne's webspace) and if you get stuck, ping me. What happens is, you transform your XSLT into something Saxon JS can work with, and then you post that in your webspace. We'll both be reading the documentation these next few days...can we try to get this up and running perhaps on the weekend?

[NADGIT]

So I install it in the webspace? Is it sort of like a file I upload to the server then? I'll see if I can find some documentation to explain that.

[ebeshero]

@NADGIT Here's what we need to read: http://www.saxonica.com/saxon-js/documentation/index.html

[wendellpiez]

Not that it matters -- I am all for skipping the training wheels -- but XMLJellySandwich is SaxonJS, and if you run any of the examples at https://wendellpiez.github.io/XMLjellysandwich/ you will be running SaxonJS.

For example, there's the Versifier at https://wendellpiez.github.io/XMLjellysandwich/Versifier/teller.html

Its HTML driver page, runtime XML source, and XSLT are here:

• https://github.com/wendellpiez/XMLjellysandwich/blob/master/docs/Versifier/teller.html
• https://github.com/wendellpiez/XMLjellysandwich/blob/master/docs/Versifier/catalog.xml
• https://github.com/wendellpiez/XMLjellysandwich/blob/master/docs/Versifier/versifier.xsl

In particular, the HTML file shows how things are stitched together for SaxonJS. The poems themselves are loaded dynamically when links are traversed (in response to events as coded in the XSLT).

This works in your browser since GitHub Pages is set up to deliver the docs subdirectory in the repo statically in response to calls on wendellpiez.github.io/XMLJellySandwich. This means that publishing new examples amounts to committing them into the repository. One could do the same in any repo with a web server pointing at it.

It also means that one approach is to fork the repo, put it behind a web server, and start messing with it. The catalog and poem library can be extended without touching the XSLT.

In my experience, the only difficult thing about this model of development is that compiling the XSLT for SaxonJS (using Saxon or oXygen to compile it into the as-delivered form, SEF) inserts a step into the development cycle, and given the nature of XSLT especially, this can make debugging more challenging than otherwise.

Compensate for this by starting first with a reliable and well-understood XML and an XSLT demonstrated to work outside SaxonJS.

[NADGIT]

Thank you very much @ebeshero and @wendellpiez. I got the saxon-js working just fine.

http://bloodborne.newtfire.org/fetchResults.html?id=Cathedral_Ward

(try typing Upper_Cathedral_Ward, Forbidden_Woods, or Byrgenwerth after the 'id='!)

I really owe you guys alot. The API was really, really easy to use and I never would've known about this otherwise. I was coming close to giving up.