Re: If you are not tracking SQL-Ledger...a summary

[Christopher Browne]

> >Technology is changing so qickly, so by the time the standards are
> produced they become outdated. 
>  
> Yet, basic accounting doesn't.  Creative ENRON account will change however 
> :-)
>  
> >For example I see SQL-ledger.org going in this direction very quickly.
>  
> Mr. Simader has not been following the standards issues to date.  
> I am not sure if he wants to implement whatever he thinks of, or what 
> the standard(s) say should be implemented.

The two "standards" I'm aware of that would _arguably_ be relevant to 
SQL-Ledger would be:
  a) The CORBA interfaces for G/L and AR/AP;
  b) Standardized output schemes where financial reports are generated 
     in a particular form of XML.

SQL-Ledger has ignored both, and I frankly see little reason for developers to 
concern themselves with these things when they're not being at all widely used 
to provide any interoperability.

> Correct implementations of standards allows for interoperation.  Thus, say   
> an XML based report generation software could chat with a totally different GL
> sub-system.   (a rising tide floats all boats)

The thing is, the amount of infrastructure needed to build such 
"meta-communications systems" inserts a big whack of complexity.

It's not obvious that introducing this complexity actually provides a "return 
on investment" by providing _substantially_ increased functionality.

It would be pretty neat if one were to build a payroll system that would speak 
(via CORBA, or perhaps via a SOAP interface using the same sorts of interface 
functions) to SQL-Ledger as well as to some other packages.

But it's not evident that you actually win very much from this.  Adding the 
interfaces as well as separate technologies means that the system gets more 
complex.

If we built a payroll module for SQL-Ledger (which I actually have put some 
effort into :-) ), that leverages the existing Perl code, the existing DBMS, 
the existing web server, and the existing user interface.

In contrast, if we built SQL-Payroll, a package using:
 - MySQL
 - PHP4 embedded into Apache
 - CORBA interface

This requires throwing in about 4 extra "technologies," which makes the result 
more complex and more fragile, and it probably takes more effort to implement 
it to boot.

I don't think that would be AT ALL an improvement.

To argue the value of standardisation requires that there actually be some 
demonstrable and valuable benefits provided.  So far, I don't see any "value," 
merely suggestions that it would be a "good idea."  And that's not good enough 
reason.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/emacs.html
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)."  -- Matt Welsh