Notes:
AxKit vs Cocoon: more free-form than Cocoon (follows the Perl “There's more than one way to do it” ethic), you can control and use AxKit in a variety of ways.
Allegedly faster. Runs in Apache, rather than servlet environment, so less to maintain, and can integrate more closely with other Apache modules and mechanisms.
It interoperates well with mod_perl, allowing you to use other mod_perl modules, even CGI scripts and templating engines to generate your XML. Building very app-specific session handling and logging to databases or across networks or to syslogs, for instance, or using templating engines like Mason for your non-XMLy bits.
Being based on Perl, it makes it easier to get non-XML sources and munge them in to XML. Things like the variety of XML and HTML parsers, the LWP library, backends to various databases and source code repositories all come to mind.
Being based on C, you can port heavy duty calcs to C and gain lots of speed. Or use almost any available open source or proprietary C libraries.
AxKit takes a lot of good ideas from Cocoon, adds several of its own, and expresses them all in a "scalable" manner that lets you adapt the system to your applications and to your organization.
Need ultra-pure separation between XML and native code? Ok.
Need to blend in a little native code here and there because XML technologies just isn't all powerful? Ok.
Need to combine content, logic, presentation? Ok.
Need to divide up content and various parts of the presentation in to lots of little fiefdoms and enforce the divisions? No problem.