November 15, 2004
Having worked with XBRL extensively for several years, I can offer the following concerns and observations for your consideration.
1. Managing file accessibility
XBRL depends on numerous special purpose XML files including instances, schemas and linkbases. The SEC must eliminate any risk that some one of these files ...as reported... become inaccessible or changed over time.
2. XML as primary submission
Providing XBRL as a supplement to the TEXT/HTML format is problematic in that there is a duplication that necessitates reconciliation. This is a process that would be difficult to formalize, and therefore, the tagged data should ideally represent the primary form of submission.
3. SEC needs ability to document adjusted taxonomies
Extensions to XBRL taxonomies can change or create new relationships. The SEC needs an acceptable means of processing ...or restricting... taxonomy changes and additions in a way that clearly documents the final state of relationships. It is undesirable that the XBRL processing adds any uncertainty to interpreting a filing.
4. Preparing XBRL is not dependent on software vendors.
Software demands on filers, those who create XBRL documents, are significantly less complex than requirements of full-featured XBRL processing and validating, done by those who consume XBRL. A significant number of filers will be able to prepare and submit XBRL without needing special support from dedicated XBRL processors or from accounting software vendors.
5. XML container approach
XML for SEC filings could be constructed as a framework of tags acting as a high-level container for each of the SEC forms and allowing the filer to designate the content alternative used for each. This XML could then enclose or link to identified sections/files of TEXT, HTML/XHTML, XBRL or other standard formats in the future. Small company filers would especially benefit by tagging on a limited basis.
I strongly endorse the adoption of XBRL as a means of official or supplemental reporting.
Novenber 15, 2004