What is Saxon?
The Saxon package is a collection of tools for processing XML documents. The main components are:
-
An XSLT processor, which can be used from the command line, or invoked from an application, using a supplied API. Saxon implements the XSLT 3.0 Recommendation. The product can also be used to run XSLT 2.0 stylesheets, or XSLT 1.0 stylesheets in backwards compatibility mode.
-
An XPath processor accessible to applications via a supplied API. This supports XPath 2.0 and XPath 3.1. It can also be used in backwards-compatibility mode to evaluate XPath 1.0 expressions.
-
An XQuery processor that can be used from the command line, or invoked from an application by use of a supplied API. This supports XQuery 3.1, which also allows XQuery 1.0 or 3.0 queries to be executed. With Saxon-EE, you can also use the XQuery extensions defined in the XQuery Update 1.0 Recommendation, but later working drafts of XQuery Update are not supported (W3C has abandoned work on these versions).
-
An XML Schema Processor. This supports both XSD 1.0 and XSD 1.1. This can be used on its own to validate a schema for correctness, or to validate a source document against the definitions in a schema. It is also used to support the schema-aware functionality of the XSLT and XQuery processors. Like the other tools, it can be run from the command line, or invoked from an application.
-
On the Java platform, when using XSLT, XPath, XQuery, or XML schema validation, SaxonJ offers a choice of APIs. If you need portability across different vendors' tools, you can use the JAXP API for XSLT, XPath, and XML Schema processing, and the XQJ interface for XQuery. On the other hand, if you want a more integrated and complete API offering access to all Saxon's facilities, the s9api interface is recommended. You can also dive down deeper into the SaxonJ internals if you need to: there has been no particular attempt to make interfaces private, and all public interfaces are documented in the JavaDoc. Clearly, the deeper you go, the greater the risk of interfaces changing in future releases.
-
On the .NET platform, SaxonCS offers an API that enables close integration with other services available from .NET, notably the XML-related classes in the
System.Xml
namespace. It isn't possible to use Saxon as a transparent plug-in replacement for theSystem.Xml.Xsl
processor. However, it is possible to use it as a functional replacement with minor changes to your application code.The SaxonCS product, available with Saxon 11, is a complete redesign. The previous .NET product was built using the IKVM technology, which confined it to .NET Framework 4.x. SaxonCS is built by converting Java source code to C#, and runs on .NET 5 (or also on .NET 6 for SaxonCS 11.4, and .NET 6 only for SaxonCS 11.5 and above), fitting in with Microsoft's strategic direction. The API for the new product retains many of the classes and methods from the older product, but we have taken the opportunity to modernize the design (for example by using delegates rather than interfaces for callbacks), and it's therefore likely that most applications will need to make adjustments.
Full details of Saxon's conformance to the specifications are provided in the Conformance section.
As well as features standardized by W3C, Saxon provides an extensive library of extensions, all implemented in conformance with the XSLT and XQuery Recommendations to ensure that portable stylesheets and queries can be written. These include the EXSLT extension libraries common, sets, math, and dates-and-times, and the EXPath modules binary, file, and archive. Many of these extensions were pioneered in Saxon and have since become available in other products.
These extension libraries in most cases require Saxon-PE or higher, and in some cases require Saxon-EE.