From: Todd Boyle [tboyle@rosehill.net] Sent: Sunday, August 06, 2000 7:17 PM To: xbrl-public@egroups.com Subject: RE: [xbrl-public] XML Schema for General Ledger v. 06 Hi David, thanks for your comments, Vun Kannon, David said August 06, 2000, > If you see yourself writing a content model such as > > and each of e2, e3 is just PCDATA, it is time to start thinking of e2, e3, > etc as attributes, not subelements. Keeping them elements means > the order is mandatory, which is probably not necessary. Flatfile > exporters will always create the same order, that is irrelevant. > Flatfile importers have so much more to worry about that order is > not important. Well, you're absolutely right that from within XML space, attributes have advantages... your suggestion wouldn't really set back most of the flatfile geeks who I imagine, anyway. I just felt that the fixed order of the ELEMENTs would be one more way of enabling the small developer. Say for example you are a Peachtree addon developer. Peachtree GL imports can be accomplished in 6 fields. (Date,Reference,Number of Distributions,G/L Account,Amount,Description) I will provide a command line C utility, that will scream through any valid rootledgerXML file and replace the element names with quotes and commas, and delete everything else. If they want to go in both directions, I will provide another command line C utility that will reinsert the element names into Peachtree comma delimited files. The program will take me 10 minutes to write. Can you imagine how simple this program will be? I'll post the code. Any legacy General Ledger would implement this in their next version, if their developer doesn't have alzheimers. The XML developer will not be impaired at all, by a flat structure with elements only. So the burden of proof is on XBRL.org to demonstrate why a rich, hierarchic structure is sufficiently superior to my flat structure, to make it worth the disruptive killing off of all legacy GLs in the small business location. No, if anything I am looking for more ways to maximize the backward compatibility aspects of rootledgerXML. For example I will certainly add several of Eric's suggestions; I received more by email. The date needs work. The date fields needmore work. To be backward compatible, it needs a yyyy/mm/dd transaction date, and an hh:mm time. ISO 8601 date/times are fine but they are NOT backward compatible. We're not looking for rocket science here; compared with IIF and CDF and other garbage people have been struggling with for the last 10 years. > Instead of TCODE1-5, you are better off with one repeatable TCODE: > TCODE1?,TCODE2?,TCODE3?,TCODE4?,TCODE5?, > becomes > TCODE*, > > This might seem in conflict with my previous suggestion, but TCODE as an > attribute could contain a space delimited set of codes (NMTOKENS, in > XML-speak). No, that would never work in an all-elements implementation. The intention of the TCODE1-5 of course, is to provide a user definable type, which is implementation specific. For example some vendor might use TCODE1 as "weight?" and TCODE2 as "color?". A bag of commodities might have weight but no color, E.G. 100kg I am perfectly aware of many compromises being made here, in terms of what other business systems support. The reason those structures are not included in rootledgerXML is because rootledgerXML is not intended to serve as a messaging solution for business systems. Anything related to conducting a sale, purchase, inventory change, etc. will be done far better by some other XML. The purpose of rootlederXML is to enable SMBs and individuals to conduct any arbitrary types of transactions using any ASP or BSP or website that is doing a good job for them, and simply to provide a definition of the General Ledger rows so that those ASPs and BSPs can transmit the Debit/Credits for downstream reporting. 1. fiscal control/internal control, 2. cash flow/cash management, 3. consolidated views of accounts receivable and payable, 4. financial statemts/ financ reporting, 5. tax reporting, 6. consolidations and eliminations, and 7. foreign currency translations. It is necessary for BSPs to provide data to some kind of a root ledger someplace. I propose that the necessary data for the root ledger must flow to the root ledger in CDEA (classic double entry accounting) rows. An example of a root ledger GUI: http://www.gldialtone.com/webledger.htm More empirical research is needed to identify the fields and definitions that will be sufficient for all the legacy small and midrange accounting software. We could arrive at a very pragmatic definition of the General Ledger row, and then go forth and tell every ASP and BSP on the planet that the statutory GAAP and fiscal control stuff, etc. can be handled if they would kindly transmit whatever the hell they've done, in rootledgerXML format. Please work with me on this. We will email the CTOs of every one of the 2000 ASPs and BSPs in the directory at ASPNews.com, and inform them that XBRL for General Ledger contains every field necessary for 99.7% of the things that CPAs do. We will tell them that if they format their business transactions in rootledgerXML, they can deliver them by SMTP, HTTP, or middleware-- we don't care how they deliver them frankly, if they have a control total someplace giving the SMB half a chance to manage the batches. Frankly we don't care if they install the finest middleware server from the largest software company on earth. We're still going to ask for control totals at month/yearend. So they can spare everybody a lot of expense. And if these BSP subscribers' CPAs or "Quickbooks adviser" can't produce statutory GAAP, tax and cashflow management reports from transactions formatted in rootledgerXML, to give us a call and we will provide them with a little XSLT or VB or C program helper for whatever General Ledger the subscriber prefers, and refer them to another CPA who has a better grip. Do you see where I'm going with this? Time is passing. The clock is ticking. Let's provide this metaphor, that the ASP or BSP is a subledger. This is the way to enable widespread adoption of ASPs and BSPs incrementally without betting the business. CPAs should become a good citizen this time around instead of a bunch of crabby, uncooperative complainers holding up everybody's progress. * Todd F. Boyle CPA http://www.GLDialtone.com/ * tboyle@rosehill.net Kirkland WA (425) 827-3107 * XML accounting, web ledgers, BSPs, ASPs, whatever it takes * quoting the classic David Peel album