Why should I want to use a schema-aware XSLT or XQuery processor?

The short answer is that it makes it easier and faster to develop correct stylesheets and queries, especially when handling complex input or output vocabularies. By declaring the types of data that individual functions or templates are designed to manipulate, and by validating source and result data against a schema at each stage of processing, bugs are caught earlier in the development cycle. Incorrect queries and stylesheets typically produce an error message rather than simply producing incorrect output. Error messages are likely to refer to the exact point in the query or stylesheet where the error needs to be corrected, rather than simply reporting that the output of the query or stylesheet is invalid.

For more information, see Michael Kay's article on the Stylus Studio web site.

Should I use XSLT or XQuery? Are the two languages in competition?

The two languages do have a high level of functional overlap, but each language has unique strengths. XSLT 2.0 is better than XQuery 1.0 at handling the rendition of narrative (document-oriented) XML (for example it offers facilities such as format-number() and format-date()), while XQuery makes it easier to perform some of the manipulations needed when handling more rigidly-structured data. Saxon is unique in allowing the two languages to be mixed in a single application.

For more information, see Michael Kay's conference papers published at XTech 2005 and XTech 2006.

Does Saxon do static type-checking?

Saxon does not do static type-checking in the sense that the term is used in the W3C language specifications (this refers to pessimistic type checking, in which any construct that might fail at run-time is rejected at compile time). This is an optional feature of the W3C specifications. Saxon does however perform optimistic static analysis of queries and stylesheets, in which an error is reported only for constructions that must always fail at run-time. The information derived from this static analysis is also used to optimize the run-time code.

Will Saxon continue to be available free of charge?

The open-source development model has been very successful for Saxon, and the company Saxonica was established in order to make it possible to continue it. Saxonica aims to develop added-value options to the base Saxon technology that will be offered commercially, alongside the open-source product which will continue to meet the needs of most users.

In the three years since Saxonica was established, new releases of the open-source Saxon-B product have continued to be released in parallel with the commercial Saxon-SA offering, and Saxon-B users have benefited from many of the investments funded through Saxonica's commercial activities.

What are the differences between the open-source and commercial versions?

The main difference is that the commercial product, Saxon-SA, is schema-aware. This means it includes an XML Schema processor, and schema-aware XSLT 2.0 and XQuery 1.0 processors. A schema-aware XSLT or XQuery processor takes advantage of the type information extracted when source documents are validated against a schema; this gives the potential for improved error reporting and improved performance. A schema-aware XSLT or XQuery processor also allows the result document to be validated as it is being written, so for example if the stylesheet or query generates incorrect XHTML, the error can be pinpointed to the place in the stylesheet or query that needs to be corrected.

In addition, Saxon-SA offers some extra advanced features. These include a try/catch capability, allowing run-time errors to be processed by the application; an extension to handle higher-order functions; and facilities in XQuery to provide equivalents to some of the features otherwise available only in XSLT, including grouping, advanced regular expression processing, and date and number formatting. For more information, see Saxonica products

Is source code available for the schema-aware version of Saxon?

No, this software is being made available on a commercial basis, protected by a license key. If you need access to source code for commercial reasons, please contact Saxonica to discuss possible licensing terms.

Does the commercial version of Saxon include all the open-source code?

Yes. The code from Saxon-B is all present in Saxon-SA, without any modifications. Saxon-SA is built entirely by adding modules to Saxon-B. Because the open source code is not modified, there is no need to publish separate Saxon-SA versions of these modules. In the terminology of the Mozilla Public License, Saxon-SA is a larger work rather than a modification.

Who owns the IPR in Saxon?

The open-source Saxon code is developed and released under the Mozilla Public License version 1.0, which you can obtain at http://www.mozilla.org/MPL/MPL-1.0.html. This identifies two main roles: the Initial Developer, and Contributors. Early versions of Saxon were developed by Michael Kay while working for ICL, which has since been merged into Fujitsu, and the Initial Developer was identified in the license as Michael Kay of International Computers Limited.

The majority of the code in Saxon was developed by Michael Kay after leaving ICL, technically acting in the role of a Contributor. The IPR in both cases is available under the same liberal terms. The Mozilla license grants you a right to use the code, distribute it, and modify it, free of charge, for any purpose. Modifications to the code must be distributed under the same license as the original code.

A few individual modules of the code have been reused from other open-source products, or have been contributed by Saxon users. In all cases the origin of these modules is identified in the source code.

The additional code in the schema-aware version of Saxon is owned by Saxonica Limited.

Does Saxon include any third-party software?

A small part of the Saxon code (less than 3%) is derived from software modules originally developed as part of other open-source products. These components include:

• The QuickSort routine used for sorting is an implementation of C. A. R. Hoare's classic algorithm produced by Wolfgang Hoschek while working at CERN. The conditions of use are given in the source code of the module (net.sf.saxon.sort.GenericSorter). Minor changes have been made to integrate the code into Saxon.

• A number of classes for manipulating hash maps and sets with unboxed integer keys were contributed by Dave Hale and Dominique Devienne of Landmark Graphics.

• A module from Xerces, developed by the Apache Software Foundation, is used for checking the lexical validity of XML names.
  
  

• Routines for converting XPath regular expressions to Java regular expressions are based on the xsdregex package published (under the BSD license) by James Clark. Saxonica has modified these routines to target J2SE 5.0 and .NET as well as the original JDK 1.4.

• Routines for normalizing Unicode character strings are adapted from code published by the Unicode Consortium, and are used under the Unicode Terms of Use. Details of modifications made to this code by Saxonica are included in the source code of the relevant modules, which can be found in package net.sf.saxon.codenorm.

• Saxon's XPath tokenizer and parser were originally based on the equivalent components in James Clark's xt product, though they have been heavily modified since. This software has been modified and republished under James Clark's license.

• The code for analyzing and validating XML schemas was originally based on the equivalent components in Castor. Although the design of this component still follows the original structure quite closely, the actual code has been almost totally rewritten, and now provides much stricter conformance to the XML Schema specification. Castor is released under a BSD-like license which allows commercial derivatives.

• The code for validating instance documents against an XML Schema includes an implementation of algorithms published by Henry Thompson and Richard Tobin.

• The Saxon distribution includes demonstration JAXP client code that was originally published as demonstrations of the JAXP API included in the Xalan-J product from the Apache Software Foundation.

• The Saxon distribution for the .NET platform includes run-time support libraries for IKVMC and GNU ClassPath copied unchanged from the IKVM.NET distribution available at IKVM.NET. The license conditions for these components are published at that site. In the case of GNU Classpath, this is done by reference to the GNU Classpath license site.

Why didn't Saxon use the schema processor already available in Xerces?

Schema processing needs to be tightly integrated into a schema-aware XSLT or XQuery processor. By designing a new schema processor as an integral part of Saxon, it was possible to design data structures and interfaces that are optimized for use in this environment. For example, the schema processor and validator share the use of the Saxon NamePool for managing names and namespaces, and the validator is designed to slot into Saxon's SAX-like event processing pipeline used both for building source documents and for serializing output documents. This close integration also enables much better error reporting, something which is critical to the usability of a schema-aware XSLT or XQuery processor. Finally, Saxon has always prided itself on offering the highest-possible level of adherence to W3C specifications, and this would not be possible if such a critical component were outside Saxon's direct control.

How do the Java and .NET products differ?

Saxon is written in Java, and both products are built from the same source code. The difference is that Saxon on Java is compiled into Java bytecode, while Saxon on .NET is compiled into the .NET equivalent, MSIL. This is achieved using IKVMC, an open-source cross-compiler.

Saxon of course takes advantage of many of the classes in the Java Class Library. In the case of Saxon on .NET, Saxon uses GNU Classpath, an open-source implementation of the class library, which itself has been cross-compiled to run on .NET. For some critical services, however, Saxon instead uses equivalent classes provided natively by the .NET platform: examples are XML parsing, URI resolution and dereferencing, regular expression handling, and collation support.

In addition, Saxon on .NET provides a distinct API that respects the house style of .NET programming and that provides integration with other facilities on the .NET platform, notably the classes in the System.Xml namespace.

Is it true that Altova XML is three times faster than Saxon-SA?

No, Saxon is ten times faster than Altova. Or a hundred times, according to some users.

Altova measured Saxon's performance in the most unfavourable way one could imagine: running a thousand tiny transformations individually invoked from the command line. That means initializing Java from scratch each time. They weren't measuring Saxon performance at all, they were measuring the time taken to load the Java VM.

With a properly written Java test driver, Saxon takes 2 min 50 sec to run the full suite of 4864 tests, compared with the 6 min 42 sec that Altova took to run a subset of 1127 tests using their own processor. That's 28.6 tests per second for Saxon, 2.8 tests per second for Altova. The Saxon timing includes the expensive operation of comparing the results with reference results, I don't know if that's included in Altova's figures. Either way, if they're choosing to compete on performance, then they've got a long way to go.

Michael Kay's blog responds to Altova's claims in more detail. Several users have added their own observations, some claiming that Saxon is up to a hundred times faster than Altova when running real workloads.

Anyway, if they were running the W3C conformance test suite, then where are their results? And why were they only running a subset of the tests? Saxon's results are here.