Introduction

XML has, in theory, solved one of the problems facing web site developers: How to develop a consistent look across your site using a template/stylesheet system. Unfortunately a lot of the solution to that problem still remains out of reach of the majority of web sites. One major piece of the puzzle that still has not been perfected is the authoring stage. Authoring XML for non-XML savvy designers is still problematic. Some tools exist to solve this problem, such as XMetaL, but as first generation tools these still have rather large weak spots. I expect to see this side of the puzzle solved with this seasons software releases - I hope I'm not wrong.

The other side of the puzzle for web developers is delivery. Its going to be an extremely long time until all clients support some sort of client side transformation. And I remain unconvinced this is the right way to do it. Take XSLT as an example; the Apache group are right now trying to develop a way to do XSLT without building an in-memory tree structure of the XML document. However, as an implementor of XPath (Perl's XML::XPath module) myself, I think they are going to find this a really tough nut to crack. Not only that, but all this parsing is extremely resource intensive, and I think that's the wrong model to be looking at, especially when we want to deliver to handheld devices.

That leaves server side transformation. There are several available options for this. The most immediately obvious is static transformation. However that can start to become a maintainence nightmare. Then there are application servers that operate within their own world, such as Enhydra and Zope. These are excellent solutions for shops that already use those solutions. Finally there is Cocoon, a truly awsome technology, now part of the Apache project. Cocoon is a full blown Application server built around XML technology. Part of Cocoon is a system which associates stylesheets with XML files. See http://www.w3.org/TR/xml-stylesheet for details on this method. I don't personally have any gripes with Cocoon (I do have gripes with Java, but thats another issue). To an extent AxKit emulates Cocoon (although in reality, Cocoon and AxKit are just implementing suggested standards).

AxKit fits into this picture by providing simple intuitive ways for web developers to deliver XML to clients in different media formats and stylesheets. AxKit also, very much like Cocoon, provides caching facilities built into its core, so that only at single points of change will AxKit attempt to re-create the document being delivered. Unless, of course, the developer explicitly decides not to cache the document. Unlike Cocoon though, AxKit is built in perl, and integrates extremely tightly with Apache. AxKit also provides some of the technology natively that Cocoon 2 is going to deliver (AxKit also doesn't provide some of the technology that Cocoon does deliver!).