Saxon-JS usage feedback

Hello Saxonica folks,

Thanks for all your hard work and effort building a great collection of libraries. I am part of a small team building tooling around the OSCAL (https://pages.nist.gov/OSCAL/) standard for FedRAMP (https://www.fedramp.gov/). Our goal is to create reusable components for FedRAMP OSCAL validation, using Schematron assertions compiled to XSLT. We've had success building preliminary tooling, but I want to share some challenges we've had with Saxon-JS.

Because we are building open-source tooling for third-parties, we have been concerned about the licensing terms of Saxon-JS. For our own usage, we are pursuing authorization to purchase a license for Saxon-JS. However, integrators may have different expectations around licensing terms of foundational tools (like Saxon-JS), and we fear this will diminish the potential value of our work.

Additionally, we have encountered a few technical challenges. The largest challenge being the lack of asynchronous network IO, which creates performance issues. In an attempt to prevent the browser UI from locking up during processing, we pursued usage of a Web Worker, but this has proven to be problematic due to the lack of required DOM API availability in that context. I understand from browsing this board that this is on the roadmap - but I would like to share that we consider the usage of synchronous IO to be a critical issue.

As you may recall I submitted a prior bug, which we were pleased was very quickly resolved (https://saxonica.plan.io/issues/5008). However, it has not been released as of yet, and that has challenged us to reevaluate our approach. If Saxonica were to communicate a release cadence, or do more frequent releases, that would alleviate our concerns.

Not being privy to Saxonica's business concerns I hesitate to suggest, but I would add that a more permissive license - coupled with acceptance of community pull-requests on a public repository - would address these concerns and promote more community collaboration around the library. For instance, upgrading the library to support ECMAScript 6 modules or adding Typescript typings are things we would have considered assisting with, but are not given the option.

Thanks for reading, and your consideration of the perspective of one member of your user community.

Replies (1)

RE: Saxon-JS usage feedback - Added by Michael Kay over 3 years ago

Thanks for the feedback.

At present Saxon-JS development has been funded entirely from sales of the Java Enterprise product, so we have a situation where one group of users are subsidising another. While I value the benefits that come from open-source projects, I've seen too many of them build a large user base and then fail to find a source of revenue to fund further development - libxml is probably the classic example of that, and we've experienced it more painfully with IKVM. I want to find a sustainable model where the value that users get from the technology feeds back into further innovation. The fact that Saxonica is still developing XML technology when nearly everyone else has given up is evidence, to my mind, that this approach is beneficial to the user community. My hope is that we can grow the Saxon-JS user community to a point where (as with Saxon on Java) we can fund further development from revenue gleaned from the top 10% of users.

I probably haven't been adventurous enough in encouraging contributions from the user community. There have been many occasions when users have volunteered code, but when I asked for test cases and documentation updates, they never appeared. I know that one of the reasons is that we haven't invested enough in the tools and processes for continuous integration to make this work properly, and we've been trying to correct that. But another reason is that quality inspection of user contributions can be very time-consuming and sometimes very unrewarding.

We're well aware of the importance of doing asynchrony. It's hard! I don't know if you've read my Balisage 2020 paper on the topic, which is essentially an exploration of the problem space rather than containing definitive solutions. The Javascript processing model makes it very difficult to host a different programming language with a different processing model on the same execution platform.

(1-1/1)

Please register to reply

Project

Profile

Help

Saxon » SaxonJS