Why Choose AxKit?

AxKit is based on a plugin architecture. This allows the developer to very quickly design modules based on currently available technology to achieve: New stylesheet languages, new methods for delivering alternate stylesheets and new methods for determining media types. Because it's built in perl, these sort of plugins are incredibly simple to develop. Not long after releasing AxKit, a developer wrote a file suffix stylesheet chooser module, which returns different stylesheets if the user requests file.xml.html or file.xml.text, in just 15 lines of code. This plugin architecture also makes developing new stylesheet modules very simple, using some of the readily available code in Perl's excellent CPAN (the Comprehensive Perl Archive Network). A stylesheet module to deliver XML-News files as HTML would only take a few lines of code based on David Megginson's XMLNews::HTMLTemplate module, and AxKit works out all the nuances of caching for you.

Another important part of this is that AxKit is pragmatic about what it delivers to clients. It doesn't have to be HTML, or XHTML, strict HTML 4, or indeed compliant to any particular standard. This decision was made because no matter what, clients are still not going to upgrade their browsers just because you want them to. So AxKit says that you can deliver XML or XHTML if you want to (and the tools are there for you to do so), but its just as easy to deliver any other format.

AxKit comes with a number of pre-built stylesheet modules, including two XSLT modules: one built around Perl's XML::XSLT module, a DOM based XSLT implementation that is in the beginning stages, and one built around Ginger Alliance Ltd's Sablotron XSLT library, which is a much more complete XSLT implementation built in C++, and is extremely fast. For the closet XSLT haters out there (come on - I know there are quite a few!) there's XPathScript - a language that takes some of the good features of XSLT, such as node matching and finding using XPath, and combines it with the power of ASP-like code integration and in-built Perl scripting. XPathScript also compiles your stylesheet into native perl code whenever it changes, so execution times are very good for XML stylesheet processing. As an example of XPathScript's power, I've created a DocBook stylesheet that dynamically can show separate sections of a DocBook/XML file.

The core of AxKit is also very quick. Delivering cached results it runs at about 80% of the speed of Apache. It achieves this primarily because it's built in mod_perl. The tight coupling with Apache that mod_perl provides means that an awful lot of the code is running in compiled C. In order to deliver cached results, AxKit just tells Apache where to find the cached file, and that it doesn't want to handle it. Apache comes up with the goods at its usual lightning speed.

Finally, AxKit works hand-in-hand with Apache. So any webmaster skills will not go to waste. Cocoon 2 is about to deliver a sitemap feature, whereby you don't have to use <?xml-stylesheet?> processing instructions everywhere to build up your site. AxKit already provides this, and integrates directly with Apache's <Files>, <Location> and <Directory> directives. All AxKit's configuration takes this approach, so you never have to teach a webmaster any new tricks to build up your XML site.