AxKit: XML Web Publishing with Apache and mod_perl
|Table of Contents|
One of XML's major benefits to web developers is that it is a standard way to separate data from presentation, and create a consistent templating system for a web site. Yet that promise is yet to be fully realized by many, due to the immature state of XML tool support, especially in authoring.
An important part of using XML for web publishing is content delivery. Although XML-to-HTML conversion is partially possible in browsers such as Internet Explorer, the reality is that HTML or XHTML will be served from web servers for a long time to come. This means server-side XML transformation is the most viable option for publishing with XML today.
Server side transformations can be handled at various levels. The most basic of these is static transformations (e.g., using an XSLT processor and some shell scripts), but this method can quickly become awkward, and is not satisfactory for dynamic web sites.
Another option is application server environments such as Zope or Enhydra. If you have a real need to use these products, they are a good choice. But keep in mind that they have a tendency to operate within their own enclosed universe.
A third choice is to use an XML content delivery infrastructure such as that provided by the Apache Cocoon project. Cocoon is a Java-based environment for pipelined transformation of XML resulting in web pages served to the user. It also offers more advanced features for active server pages etc.
AxKit, a mod_perl and Apache-based XML content delivery solution, takes an approach similar to Cocoon. It provides simple ways for web developers to deliver XML utilizing multiple processing stages and style sheets, all programmable through Perl. AxKit takes care of caching so that the developer doesn't have to worry about it. It's also tightly bound to the Apache web server, providing a good route forward for those with an existing investment in mod_perl and Apache.
The fundamental way in which XML is delivered to a client in AxKit is through transformation with one or more style sheets. AxKit does not see style sheets solely in terms of XSLT transformations, but as more generic processing stages allowing arbitrary languages and operations.
In this article, I will describe AxKit's architecture, and give details of its installation and future development. Some familiarity with transforming XML would be helpful in reading this article.
AxKit is based on a plugin architecture. This allows the developer to quickly design modules based on currently available technology to create
- new style sheet (transformation) language;
- new methods for delivering alternate style sheets
- new methods for determining media types
Because AxKit is built in Perl, these plugins are simple to develop. Not long after releasing AxKit, a developer wrote a suffix-based style sheet chooser module (which returns different style sheets if the user requests file.xml.html or file.xml.text) in just 15 lines of code!
The plugin architecture also makes developing new style sheet modules easy, using some of the readily available code in Perl's excellent CPAN (the Comprehensive Perl Archive Network). A style sheet 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.
AxKit comes with a number of pre-built style sheet 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 and fast XSLT implementation built in C++.
For the closet XSLT haters out there, there's XPathScript -- a language of my invention that takes some of the good features of XSLT, such as node matching and finding using XPath, and combines them with the power of ASP-like code integration and inline Perl scripting. XPathScript also compiles your style sheet into native Perl code whenever it changes, so execution times are very good for XML style sheet processing.
The core of AxKit delivers good performance. Serving 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 a 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 then serves the page with its usual efficiency.
Finally, AxKit works hand-in-hand with Apache. So any webmaster skills you might have
in Apache administration won't go to waste. AxKit integrates directly with Apache's
All AxKit's configuration takes this
approach, so you won't have to teach a webmaster new tricks to build
up your XML site.
Pages: 1, 2