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. Unlike translations, these stylesheets (and associated schema) will have to change at unpredictable and often inconvenient times quite separate from any gnucash development timeline. We may be better to make a clear dividing line that gnucash supports the method but not the individual stylesheets. Each would then be submitted to the relevant authority by a citizen under the remit of that authority for independent assessment. (Authorities might not accept a submission from a non-citizen.) Tax and government policy cannot be relied upon to change within the design parameters of any format, no matter how generic. There will be times when the stylesheets will need radical overhauls at little or no notice. After all, we would be trying to keep up with forces over which we have no direct control. It could make organising the work of a team like Samba look trivial! It takes time for a citizen to understand how government budget changes affect payroll and personal/business taxation - it is much more difficult for a developer living in a different system to change an internal structure to conform to such arbitrary changes. To expect to retain any compatibility with other systems that are absolutely unrelated is more than ambitious. All we can hope to do is provide a core format and let others do the specifics. 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. Not to put too fine a point on it, we could end up needing official advice from an accountant in each region! (Which is one reason why Intuit QuickTax costs money every single year.) e.g. in the UK recently, the government added a tax credit system for working families and the disabled. In each of the subsequent budgets, it was reviewed, changed, transformed or just tweaked. Highly paid accountants spent months deciphering the law for their corporate HR departments and *still* got it wrong. The Inland Revenue designed the system and THEY got it wrong - overpaying some individuals by thousands of pounds. The entire tax credit system is administered via payroll deductions done by the employer upon notification by the Inland Revenue of the results of means tests. The entire system was reworked again this financial year and is now a single tax credit but it's still not clear, unambiguous or easy to implement. Then there are student loan deductions, child support agency deductions, the list goes on. > 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. FYI, cashutil has a build-time dependency on xsltproc (which then depends on libxslt). 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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpFilowkrVgg.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel