Adding Payroll

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> On Tuesday 08 November 2005 9:38 pm, Derek Atkins wrote:
>> We already depend on libxml2, so it wouldn't add a new dependency
>> to use it yourself.  OTOH I do like Neil's approach of creating a
>> generalized XML output and then an XSL translator from the general
>> output to the specific IRS XML schema.  This way it doesn't require
>> C coding to add new output formats; it just requires a new XSL template.
>
> There's no inherent reason why gnucash has to do this XSL work directly - it 
> could be handed over to a perl or bash script. OK it might be nice to do it 
> ourselves but that just means gnucash has to have some way of controlling or 
> predicting / finding the stylesheets to use and further encourages the user 
> to believe that it is *our* collective role as gnucash developers to keep 
> those stylesheets updated with each budget cycle - across all financial and 
> geographic boundaries. IMHO, that is a task to which we are currently not 
> well suited. 

True, but I see no reason why not to write the code in gnucash to
take the output XML and run it through a user-defined XSL template.
The default template can be a user preference, or perhaps even
chosen at each runtime..  We don't necessarily need to distribute
the XSL templates, or perhaps we install them into /usr/share/doc/
instead of /usr/share/gnucash..  Still, I believe that requiring an
external perl or bash script just to run an XSL template is a
disservice to our users.  However I agree that we should make it
clear in the UI that WE are not responsible for the XSL templates.

> It is a *very* similar issue to the current US-centric tax code
> support - the dream of supporting the tax codes for each population
> for whom we currently have translations is just that - a dream.

Sort of..  The way the "tax report" is currently implemented is...
poor.  It's not done well, IMNSHO.  It should be much easier to "plug
in" new versions.  Having some template is certainly a reasonable
means to do it.  Then we just need to implement the template runner,
and let users create/supply the templates.

>> The downside of this approach is that it DOES add a new dependency
>> on libxstl, which we currently do not depend on.
>
> Not necessarily. Much like OFX and cashutil, payroll will not be needed by 
> every single gnucash user so it's an optional add-on. Any dependencies are 
> therefore optional too. 

Optional dependencies are still dependencies.

> FYI, cashutil has a build-time dependency on xsltproc (which then depends on 
> libxslt).

build-time deps are largely irrelevant for the vast majority
of users.  It's run-time deps that matter.

> What gnucash has done so far is largely region-neutral at it's core with 
> optional modules (like OFX) that are region-specific. It is a model that has 
> served us well.
>
> If we stick with the core functionality, we may not need an xsltproc 
> dependency at all.

Maybe.  I still think gnucash needs to have the ability to run
the templates..  Which means we need to depend on the template
runner -- whatever template system we use (e-guile, xslt, etc).

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available