XML Publishing with AxKit

Introducing AxKit, an XML Application Server for Apache

Originally conceived in 2000 by Matt Sergeant as a Perl-powered alternative to the then Java-centric world of XML application servers, AxKit (short for Apache XML Toolkit) uses the mod_perl extension to the Apache HTTP server to turn Apache into an XML publishing and application server. AxKit extends Apache by offering a rich set of server configuration directives designed to simplify and automate common tasks associated with publishing XML content, selecting and applying transformative processes to XML content to deliver the most appropriate result.

Using AxKit’s custom directives, content transformations (including chains of transformations) can be applied based on a variety of conditions (request URI, aspects of the XML content, and much more) on a resource-by-resource basis. Among other things, this provides the ability to set up multiple, alternate styles for a given resource and then select the most appropriate one at runtime. Also, by default, the result of each processing chain is cached to disk on the first request. Unless the source XML or the stylesheets in the chain change, all subsequent requests are to be served from the cache. Figure 1-4 illustrates the processing flow for a resource with one associated processing chain consisting of two transformations.

Figure 1-5. Basic two-stage processing chain

In its design, AxKit implements a modular system that divides the low-level tasks required for serving XML data across a series of swappable component classes. For example, Provider classes are responsible for fetching the sources for the content and stylesheets associated with the current request, while Language modules implement interfaces to the various transformative processors. (You can find details of each type of component class in Chapter 8.) This modular design makes AxKit quite extensible and able to cope with heterogeneous publishing strategies. Suppose that some content you are serving is stored in a relational database. You need only swap in a Provider class that selects the appropriate data for those pages from the database, while still using the default filesystem-based Provider for static documents stored on the disk. Several alternative components of various classes ship with the core AxKit distribution, and many others are available via the Comprehensive Perl Archive Network. Often, little or no custom code needs to be written. You simply drop in the appropriate component and configure its options.

We will look at each AxKit option for creating style processing chains in depth in Chapter 4. But for now, recall the collection of poems that you marked up using the poemsfrag Document Type Definition earlier in this chapter. Also, remember that when you left off, you were a bit stuck: the poems’ markup captured the content in a semantically meaningful way, but by abandoning HTML as the source grammar, you lost the ability to just upload the document to a web server and expect that browsers would render it properly. This is precisely the type of task that AxKit was designed to address. Figure 1-5 illustrates a single source document containing a poem and three alternative processing chains implemented as named styles that can be selected at run-time to render that poem in various formats.

Figure 1-6. Alternate style chains

Here is a sample configuration snippet that would implement these styles, making each selectable by adding a style parameter with the appropriate value to the request’s query string:

 <Directory /poems>
     <Files *.xml>
         # choose styles based on the query string
         AxAddPlugin Apache::AxKit::StyleChooser::QueryString
         
         # renders the poem as HTML
         <AxStyleName poem_html>
             AxAddProcessor text/xsl /styles/poem2html.xsl
         </AxStyleName>
         
         # generates the poem as PDF

         <AxStyleName poem_pdf>
             AxAddProcessor text/xsl /styles/poem2fo.xsl
             AxAddProcessor application/x-xsl-fo NULL
         </AxStyleName>
         
         # extracts the metadata from the poem and renders it as RDF
         <AxStyleName poem_rdf>
             AxAddProcessor text/xsl /styles/poem2rdf.xsl
         </AxStyleName>
         
         # set a default style if none is passed explicitly
         AxStyle poem_html
     </Files>
 </Directory>

With this in place, you can put your XML documents that use the poemsfrag grammar into the poems directory and render each poem in one of three formats. For example, a request to http://that.host/poems/mypoem.xml?style=poem_pdf returns the selected poem as a PDF document. A request for the same poem with style=poem_rdf in the query string offers the metadata about the selected poem as an RDF document. In each case, the source document does not change. Only the styles applied to its contents differ.

Finally, it worth noting here that AxKit is an officially sanctioned Apache Software Foundation (ASF) project. This means that AxKit is not an experimental hobbyware project. Rather it is a battle-tested framework developed and maintained by a community of committed professional developers who need to solve real-world problems. No project of any size is entirely bug-free, but AxKit’s role as an ASF-blessed project means, at the very least, that it is held to a high standard of excellence. If something does go wrong, its users can fully expect an active community to be around to address the problem, both now and in the future.