Saxonica: Why Saxon?

Why choose Saxon?

The Saxon-EE product includes within a single package:

The main Saxon product is written in 100% Java and therefore runs on any popular platform. SaxonCS for .NET and SaxonC for C/C++, PHP, and Python are produced by cross-compiling the code and adding custom APIs to further extend the range of platforms supported. SaxonJS provides a JavaScript XSLT processor enabling XSLT 3.0 code to run in the browser or Node.js.

High performance and standards conformance

In the 15 years that Saxon has been available, it has established a reputation for fast performance, the highest level of conformance to the W3C specifications, excellent diagnostics, technical innovation, and responsive technical support direct from the developers.

XSLT 2.0 and 3.0 processing

Many XSLT processors (for example the default processors that come bundled with your web browser, or with Java, .NET, PHP, or Python) only support the XSLT 1.0 standard, which dates back to 1999. The web has moved on since then, and so has XSLT, with the XSLT 2.0 specification published in 2007, and XSLT 3.0 following in 2017. Saxon has always been ahead of the pack in implementing new versions of the W3C standards, as you would expect, given that Saxon's lead developer, Michael Kay, was the editor of both the XSLT 2.0 and 3.0 specifications.

XSLT 2.0 and 3.0 offer order-of-magnitude improvements in functionality, performance, and productivity compared with 1.0. Popular features introduced in 2.0 include grouping capability, regular expressions for text processing, date-and-time manipulation, and creation of multiple output files; while 3.0 brings support for processing JSON alongside XML. As a measure of the increase in capability, the standard function library for XSLT 1.0 contains just 36 functions, which increases to 126 in XSLT 2.0, and 215 in XSLT 3.0. The new features added to the language not only make it possible to write applications that would be inconceivable under XSLT 1.0 (an example would be a stylesheet to render complex datasets graphically using SVG), but they also make the code more compact, readable, and maintainable, all of which improves developer productivity.

Additional features

Saxon-EE completes the picture by offering the enterprise class features including an advanced optimizer, schema-awareness (giving improved productivity by detecting programming mistakes earlier and diagnosing them more accurately), streaming capability (needed for transforming large documents), bytecode generation for high performance, and improved integration facilities.

Java integration

The Saxon XSLT engine supports standard Java application programming interfaces, which means you only need to change a single environment variable to use Saxon in place of the processor bundled with your Java Development Kit. Many users have reported that this has speeded up applications tenfold.

Saxon integrates with many popular Java XML libraries such as JDOM, DOM4J, XOM, and AXIOM.

XQuery processing

Saxon also provides an XQuery 3.1 processor. This gives you a choice of languages supported by the same underlying engine. Saxon was the first product to offer XSLT and XQuery in an integrated package, allowing you to use each language for the things it does best. The two interfaces are complementary: for example you can write a function library in XQuery, and call the functions from your XSLT stylesheets. Saxon has established a reputation as the XQuery engine of choice, as shown by the number of vendors who are integrating it into their XML development environments.

XQuery 3.1 is the latest version of the language, approved as a W3C Recommendation in March 2017. This version makes XQuery (and also XPath and XSLT) into a full functional programming language, which means it is capable of being used for much larger and more complex applications, with a much higher level of reusability of code.

A word of advice, though: Saxon is not an XML database. Users have successfully used Saxon to process XML datasets up to a gigabyte in size, but the product does not attempt to offer the kind of facilities associated with a traditional database, such as transactions, concurrency, and recovery.

Schema processing

Saxon-EE offers an alternative choice of XML Schema processor. Again, Saxon is in the lead implementing new W3C standards: its implementation of XML Schema 1.1 is now complete. This version removes many of the frustrations of the previous 1.0 version by adding features such as assertions and conditional type assignment. Users of XML Schema 1.1 report that they are achieving much higher data quality because of the increased ability to set precise validation criteria. The Saxon schema processor also emphasizes usability: since the main aim of schema validation is to detect errors in instance documents, the quality of the error reporting is paramount.

XSLT in the browser

When XSLT was first introduced, it was seen as the perfect way to gain the full benefits of XML, separating content from presentation and allowing information assets to be repurposed for different devices and different audiences. The ideal place to perform device-specific processing is in the device itself, so XSLT-in-the-browser was a natural fit. Unfortunately, though, it took many years for all the browser vendors to reach an acceptable level of XSLT 1.0 standards conformance, and by the time it happened, the web had moved on from displaying static pages to fully interactive content delivery. The SaxonJS product fills this gap. Written in JavaScript, it provides the full capabilities of XSLT 3.0 in any modern browser, taking advantage of server-side precompilation and optimization to prepare the code for fast execution. In addition SaxonJS includes extensions to the XSLT language that enable fully interactive applications to be written without dropping down into low-level JavaScript event-handling code.

See also: