implementing xbrl, 2005

Implementing XBRL This document describes one of the ways of automating report generation. XML: The Taxonomy Based Data format Extensible Markup Language (XML) is a universally preferred data description language used to describe the data we store, manipulate, and exchange via the web. The basis for this technology is a "tagging" process by which each value, item, and descriptor, etc. in the exchanged information can be given a unique set of tags with which to describe it. Using these tags, computer programs can read the data without human intervention. In short, XML is a language designed to develop other languages, such as XBRL. Taxonomy Standards, Public and Private XML is a language designed to develop other languages. We have all used “tags” to exchange information. What’s your “NAME” and “PHONE” number? What is the “BALANCE” of my account? XML uses groups of tags in the form of “Taxonomy” to describe data for a particular audience. Ernst & Young LLP is a founding sponsor of XBRL International which is developing Business Reporting Taxonomies (XBRL). These taxonomies will be used when storing or exchanging financial and operational information internally in a company, and when reporting externally to investors, analysts, regulators and customers. Its global standards consortiums are currently developing taxonomies for both vertical industry and horizontal cross-industry groups. What Is an XBRL? XBRL is an XML based taxonomy with which users can prepare, publish (in a variety of formats), exchange and analyze financial statements and the information they contain. An XBRL Instance Document is a business report, such as a financial statement prepared to the XBRL specification. The meaning of each value in the Instance Document is explained by the taxonomy. An XBRL enabled application will read this information and compare it to a published XBRL definition, and extract the information accordingly. XBRL is developed by XBRL International, a consortium sponsored by the American Institute of Certified Public Accountants started in 1999.

Evgenios Skitsanos © 2005 2

This group is committed to developing and promulgating a world-wide standard, and corresponding taxonomies, for storing or exchanging business reporting information. XBRL is gaining acceptance throughout the business reporting community. The XBRL consortium developing the taxonomies required by many web enabled reporting processes has completed a great deal of work. Acceptance and implementation of this new standard is driven by heightened emphasis on financial reporting requirements such as those described in the Sarbanes-Oxley Act. Executives, financial reporting process owners and IT professionals should consider the following points when developing an implementation strategy for XBRL.


USFRTF Framework Summary Taxonomies and On-fly Report Generation The US Financial Reporting Taxonomy Framework is a collection of XBRL taxonomies that will be used to express the financial statement-based reports of both public and private companies across all industry sectors. Different components of the framework will be used for different reporting purposes, and new components will be added over time to cover more diverse reporting needs. Summary of types of Components or Layers The following is a summary of the types of components or “layers” contained in the US Financial Reporting Taxonomy Framework:

• Stand alone add-ons • Common terms • Industry terms

Stand Alone Add-ons Stand Alone Add-ons are self-contained DTSs that may be used by creators of XBRL Reports. These components include a schema file and all linkbases (presentation, label, calculation, reference and definition) as appropriate. They are not referenced or imported by the GAAP Industry extension DTSs because they:

• Are not universally needed by users of the Industry Extension Taxonomies

• May be updated, superseded or replaced by other external components independent of changes to the Industry Extension Taxonomies

Users who wish to take advantage of the Stand Alone Add-Ons can either import the add-on components into their company extension taxonomy or use the add-on components directly in their instance document. NOTE: In previous versions of the taxonomy framework, these components were imported directly into the Industry Extension Taxonomies. Industry Taxonomy Layer


Users creating company extensions or instance documents will normally select a single primary taxonomy from the Industry Taxonomy Layer. The Industry Taxonomies specialize and extend the concepts defined in the common terms layer and build relationships between these concepts using the presentation and calculation linkbases. Components The following is a summary of components in the USFRTF: Namespace

Prefix Name Layer Description

int-gcd Global Common Document

Stand Alone Add-on Contains information that is specific to the document being created or the entity that issues the document. For example, general information about the title of the document, its creator, revisions to the document, the name of the entity and the industry in which the entity operates.

usfr-ar Accountants Report Stand Alone Add-on Contains information that describes the independent accountants’ report, if one is issued, such as the name and signature of the independent auditor/accountant.

usfr-fst Financial Services Terms

Common Terms Layer This financial reporting taxonomy is intended to provide detail level accounting terms that are typically included in financial statements. This taxonomy includes such terms that are common solely to the financial services sector.


usfr-mda Management Discussion and Analysis

Stand Alone Add-on Includes information for the section of then annual report where the company’s management provides analysis on results of operations, financial position and other issues.

usfr-mr Management Report

Stand Alone Add-on Information contained within the Management Report which typically accompanies audited financial statements.

usfr-pt Primary Terms Common Terms Layer This financial reporting taxonomy is intended to provide detail level accounting terms that are typically included in financial statements. This taxonomy includes such terms that are common to multiple major industries.

usfr-sec-cert

SEC Officers Certification

Stand Alone Add-on Information contained in the Officers Certification report as mandated by the Sarbanes-Oxley Act 0f 2002

us-gaap-ci Commercial and Industrial Companies

Industry Taxonomy Layer

This taxonomy is intended to provide the accounting concepts and relationships to allow Commercial and Industrial entities to express their financial statements in XBRL. This taxonomy builds on top of the Common Terms layer and may serve as the basis for further details industry extensions.

us-gaap- Banking and Industry Taxonomy This taxonomy is


basi Savings Institutions Layer intended to provide the accounting concepts and relationships to allow banking related entities to express their financial statements in XBRL. This taxonomy builds on top of the Common Terms layer.

us-gaap-ins Insurance industry Industry Taxonomy Layer

This taxonomy is intended to provide the accounting concepts and relationships to allow insurance related entities to express their financial statements in XBRL. This taxonomy builds on top of the Common Terms layer.

Elements The basic strategy for elements is to provide one element for one financial reporting concept. If there is reasonable question as to whether two concepts are always identical, the taxonomy errs on the side of creating two elements, rather than forcing what may be two concepts into one concept. Each element within a taxonomy has a unique name and ID expressing a unique financial reporting concept. Element names have been created in conformance with the LC3 convention as prescribed in FRTA 1.0. Element names remain largely unchanged from previous versions of the taxonomy framework; a map of name changes for those that have been modified will be circulated with the taxonomies. This version of the taxonomy framework contains a robust level of elements for the disclosures typically found in the financial statements for the selected industries. Building on to the methods used to create, validate and test the previous iterations of the taxonomy; additional efforts have gone into analyzing a wider range of financial statements to ensure the taxonomies have sufficient elements to meet market needs.


However, it is not practical or realistic to include every possible accounting concept or disclosure in these common taxonomies due to company specific disclosures and aggregations. It is expected that many if not all companies will require an extension taxonomy to cover those terms not in the taxonomy. Elements for the notes to the financial statements are provided on a summary level throughout, and in varying levels of detail for certain specific notes. Over time, this framework of disclosures for the notes to the financial statements will be built out to provide all of the detailed elements required. It is possible to tag a complete set of notes to the financial statements using the taxonomy as its structured today; future efforts will provide the capability for this tagging to occur at a more detailed level. Labels A unique, standard label (standard label role) is provided for every element within each taxonomy. A full set of labels is also provided for the terse label role, these labels are NOT unique. Additional label roles are utilized on an as needed-basis, for example period end labels. All labels are in English as used in the United States. Additional labels for different labels may be provided at a later time. For example, the US Domain Working Group is currently working with the Japan Domain Working Group to explore how to provide a set of Japanese labels for the taxonomy. As with previous versions of the taxonomy, documentation or ‘human readable’ definitions are provided for the elements in the taxonomy. These brief descriptions are intended to provide users with an easy, non-authoritative mechanism to understand the accounting or reporting concept that an element represents. In previous versions of the taxonomies, these definitions were included the XML Schema “documentation” element of the taxonomy schema. For this taxonomy release the definitions have been moved to the documentation label role of the label linkbase in accordance with FRTA 1.0 rule 2.1.13. References References are currently provided for many elements but have not yet been completed for all elements in the taxonomy. Elements in the current taxonomy release which do have references defined may not


have a complete set of references across all the different possible sources of references. The US Domain Working Group currently has a subcommittee working on updating the references to ensure consistency amongst reference sources and to complete the reference linkbase to cover all elements in the taxonomy. Presentation The presentation link base provides an organizational hierarchy of elements in the taxonomy to make it easy for users and reviewers of the taxonomy to find specific content within the taxonomy; in general terms this hierarchy follows the organization of a set of financial statements. Abstract elements are used throughout the presentation linkbase as described in rule 3.2.7 of FRTA 1.0 to provide additional organization. Separate extended link roles are also used to define the major separate presentation networks found within the taxonomies. Calculation Calculation linkbases are provided to document all calculations that are true within a context. Calculations are NOT provided across contexts as XBRL does not support these types of calculations at this time. When the formula linkbase is completed additional calculations will be provided, including calculations across contexts such as those used to express reconciliations between a beginning balance to an account, changes to that account, and the ending balance to an account (movement analysis). Separate extended link roles are used where there are multiple calculation networks for elements within the taxonomies. Definitions No definition linkbases have been provided as part of this taxonomy release; they may be included as enhancements to future releases of the taxonomy, but there are no immediate plans to create definition linkbases for the taxonomies. Sample Instance Sample instance documents have been provided for each industry taxonomy, which may be useful in helping you understand how the taxonomy works and is intended to be used. If you are confused by


something in the taxonomy, look for that information in the sample instance documents to see if the context helps explain the taxonomy content. Data fields to Taxonomy Elements mapping In order to generate XBRL Instance Document that later on used for Report generation, BaPRO uses Field-To-Element mapping technique. This mapping allows us to map database field that contains required data to XBRL Taxonomy element. During Instance Document compilation, engine will extract data only predefined by map that was made for this report type. Some of Taxonomy Elements represents formulas and in order to get appropriate data to represent in Instance Document engine have to pass additional step – calculation. Report Generation Generally speaking Report has two types of information represented on it. There are textual labels that describe information that we are reporting and actual data facts that can be represented with numbers, text or even diagram/flow chart graphics. On stage of Report Generation BaPRO engine look into Taxonomies database to collect information about how to display the report. Basically engine knows that there are some elements should be represented as data facts in final report and in order to represented in readable format engine will use labelling (among with descriptions) information found within the Taxonomy used for this report. Based on this collected data BaPRO engine can generate XSLT template that will be applied on top of Instance Document generated earlier via using data field to element mapping. XML Performance Less elements, more attributes One of the tricks to speedup XML performance is to create an XML model where you have less amount child elements used compare to number of attributes that you can embed into your xml. Very common XML usage: <line> <recordID>0000001437</recordID>


<accountID>4115</accountID> <documentID>A_AUDI</documentID> <effectiveDate>2003-02-28</effectiveDate> <description>Afschrijftermijn 12</description> <debitAmount>133.88</debitAmount> <costDesc>V-RD</costDesc> <projectDesc>OKS</projectDesc> </line>

High performance XML: <line projectDesc="OKS" recordID="0000001437" accountID="4115" documentID="A_AUDI" effectiveDate="2003-02-28" description="Afschrijftermijn 12" debitAmount="133.88" costDesc="V-RD"/>

XML in this case will spend much less time on parsing this data as it has only one element to go through compare to 9 elements as it shown in first case. Consider Element and Attribute Name Lengths Consider the length of the element names and the length of the attribute names that you use. These names are included as metadata in your XML documents. Therefore, the length of an element or attribute name affects the document size. You need to balance size issues with ease of human interpretation and future maintenance. Try to use names that are short and meaningful. Write Efficient XSLT When you develop XLST style sheets, start by making sure that your XPath queries are efficient. Here are some common guidelines for writing efficient XSLT style sheets:

§ Do not evaluate the same node set more than once. Save the node set in a <xsl:variable> declaration.

§ Avoid using the <xsl:number> tag if you can. For example, use

the Position method instead.

§ Use the <xsl:key> tag to solve grouping problems.

§ Avoid complex patterns in template rules. Instead, use the <xsl:choose> tag in the rule.

§ Be careful when you use the preceding[-sibling] or the

following[-sibling] axes. Use of these axes often involves algorithms that significantly affect performance.


§ Do not sort the same node set more than once. If necessary, save it as a result tree fragment, and then access it by using the node-set() extension function.

§ To output the text value of a simple #PCDATA element, use the

<xsl:value-of> tag in preference to the <xsl:apply-templates> tag.

§ Avoid using inline script. Use extensions written in Microsoft

Visual C# or Microsoft Visual Basic .NET to pass it as a parameter to the Transform call, and then bind to it by using the <xsl:param> tag. However, if you cache the style sheet in your application as described earlier, this achieves the same result. It then is perfectly acceptable to use script in the style sheet. In other words, this is just a compile-time issue.

Factor common queries into nested templates. For example, if you have two templates that match on "a/b/c" and "a/b/d," factor the templates into one common template that matches on "a/b." Have the common template call templates that match on "c" and "d." References

1. “US GAAP XBRL Taxonomy Framework”, by Charles Hoffman and Bradford Homer, 2004

2. “XBRL Inside”, by Evgenios Skitsanos, BaPRO © 2005