AquaXSL now includes Saxonica's open source, industry-leading XSLT 2.0 processor,Saxon-B. The default processor is still NSXML. To select your XSLT processor, open the preferences window and select your preferred implementation.

Some important notes...

AquaXSL has not been very thoroughly tested. I am pretty much releasing it as I develop it. If you have found a bug where AquaXSL will not perform a transformation as expected, you should suspect AquaXSL as the culprit before NSXML or Saxon-B. Please contact me with a bug report first, not the developers of the mentioned processors. It is extremely likely that any bug is located within AquaXSL itself.

Saxon-B is a non-schema-aware XSLT 2.0 processor. I am looking into what would be required to purchase Saxon-SA (the schema-aware paware version of Saxon) for use within future versions of AquaXSL.

Saxon-B is a pure Java product. This has several implications for its use within an Objective-C/Cocoa app:

NSXML is still the default processor. To make XSLT 2.0 transformations or to use Saxon-B, you must select it from the preferences window. This selection will persist. Why is NSXML still the default? Besides being an excellent XPath/XSLT implementation, I am very familiar with using NSXML within Cocoa applications. However, this is the first time I have mixed Java with Objective-C in a Cocoa application. I am not thoroughly confident that Saxon-B will work properly from within AquaXSL on everyone's machines. I may have set things up incorrectly, or in a non-portable fashion. If you experience problems, please provide feedback to me. The AquaXSL version number should probably be 0.2, not 1.1. But hey... it's free.

You'll notice that transformations with Saxon-B are much slower in AquaXSL than those powered by NSXML. This should not necessarily be regarded as indication of relative performance of these two toolkits. Disregarding the different capabilities (XSLT 1.0 vs 2.0/XQuery, etc.) of the two products, Saxon-B is at a severe disadvantage to NSXML within AquaXSL. NSXML is Objective-C-based, and therefore can run natively within the same process as AquaXSL itself. The Java-based Saxon-B, however, is currently run from AquaXSL in a unique JVM process for every single transformation. Additionally, in order to bridge the gap between Java and Objective-C when using Saxon-B, AquaXSL does a significant amount of file I/O! This puts Saxon-B at a serious performance disadvantage. As for which toolkit is actually faster with all conditions being equal, I do not know or care... and AquaXSL will not be helpful in determining this.

AquaXSL 1.1 is a very humble entry into the realm of XSLT debuggers. It's text editing features are quite rudimentary. As far as XML and XSL features go, it doesn't compare with something like oXygen. So why AquaXSL? Well, for one thing, oXygen and most other XML IDEs are not free. AquaXSL is. Also, none of the popular XML IDEs and XSLT debuggers are native (Cocoa or Carbon) Mac OS X applications. AquaXSL is.

Basically, I needed a tool to help me experiment with XSLT as I'm reading Michael Kay's excellent XSLT 2.0 Programmer's Reference. And I didn't want to shell out the cash for oXygen.