This is the TODO file for AxKit. Thank you for wanting to contribute! The
first thing you probably want to do if you haven't already is to check out
the xml-axkit module from the cvs.apache.org CVS in order to get the latest
code, and to read the CONTRIB file.

IMPORTANT: please do note that a feature being listed here does NOT mean that
it has been endorsed by the AxKit community as something that must happen, as
a good idea, or as something that if it happens should happen in the way that
is described here. So before you jump on an item and hack it into AxKit you
always want to ask the axkit-devel list about it and tell us what you think
you'll be doing in that area. Paying a visit to #axkit can certainly help as
well. In any case, the cumulated experience of the folks that dwell there
will certainly be of great help to you as you try to add something to AxKit.
Remember that this is a community thing, we need consensus ;-)


  . Eliminate dependency on Apache / mod_perl

    This is a rather large undertaking. It is not technically hard though.
    The current AxKit relies heavily on Apache and mod_perl, which means that
    it can't be used as a generic publishing system or as a CGI module. The
    Apache handler that drives the code needs to be abstracted away so that
    AxKit can be driven by any kind of request, the Configuration needs to
    have an alternate format to work outside of Apache, Apache::Fake needs to
    be used to emulate $r and other such things.


  . Documentation

    This is the job of the axkit-docs project. It really needs to be done and
    can use all the help that it gets. This would be a nice way to learn
    AxKit's internals if you are not familiar with them. Ask the
    axkit-docs@axkit.org list.


  . Make the configuration fully XML

    The configuration as it is now is ok overall, but it's hard to extend
    without writing some C code, which is a pain. Switching to an XML syntax
    would be a big win, though we don't want to make the mistakes the Cocoon
    folks made. We probably also want to make the syntax extensible with
    namespaces.


  . XSP executed twice when using the '.' href

    It has been reported that when using '.' as the href for the XSP
    stylesheet the XSP is executed twice. This has to be investigated, in the
    meantime one should use the preferred 'NULL' instead of '.'.


  . Splitting XSP out

    Currently XSP is tied into AxKit but it would make a marvellous
    standalone module for XML processing.


  . Better error messages here and there

    There are cases when the error messages aren't all that good. These need
    to be addressed. A good example is AxKit::XSP::Util that apparently
    doesn't warn properly when it fails to grab content, as well as
    XML::LibXML that happily blows up when it's fed an empty string.


  . SAX Language module

    There ought to be a module that can take SAX Machines descriptions (which
    probably need a language of some sort) and use those as any other part in
    the pipeline.


  . Provider Extensions for write access

    There are cases in which it could be useful to have a pipeline similar to
    the one AxKit has on the way out, but working in the opposite direction,
    say for instance to transform form input into storable XML.


  . New providers

    New plugin providers would surely help. A good example could be a
    provider that uses an XML DB on the backend.


  . Separate Provider for stylesheets

    It would appear that one of the main problems people have when writing
    providers is that stylesheets are also looked up through them, which
    causes various problems to people. One (backcompat) way of doing this
    would be to have it still work this way if no AxStyleProvider is setup,
    but AxStyleProvider would be able to override AxProvider.


  . More control on the interaction between the configuration and PIs

    Some would like it to be possible to use both the configuration and PIs
    simultaneously, either by having the possibility of ignoring PIs
    completely, or by allowing one to append/prepend/insert the PIs into the
    style list.


  . Relative URIs in XSLT

    This is a long standing issue that needs to be addressed as it confuses
    many people (and bothers the ones that aren't confused).


  . A good test suite

    Testing modperl apps is notoriously hard. Thankfully a framework has been
    created for that and it has to be adapted to AxKit. Also, eliminating the
    dependency on modperl might make that a lot easier.

  
  . Make Taint safe

    I believe AxKit doesn't run under PerlTaintCheck. This needs to be fixed.


  . i18n support

    AxKit should provide a global policy for xml:lang support. The way it is now,
    a user must either do processing of that element himself or rely on a particular
	module's implementation. Moreover, in XSP difficulties can arise. Having a
	global xml:lang policy would make multi-language support easier.

  . Binary data support

    It's easy to be bitten when dealing with binary support in AxKit. It should be 
    possible to flag one's output (at *any* stage) as binary, and have 
    binary-unsafe operations (such as char conversion, xml parsing, etc.) be
    skipped.