1. 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.

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.
Evgenios Skitsanos © 2005 2

3. 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
Evgenios Skitsanos © 2005 3

4. 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
Name Layer Description
Prefix
int-gcd Global Common Stand Alone Add-on Contains information
Document 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 Common Terms Layer This financial
Terms 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.
Evgenios Skitsanos © 2005 4

5. usfr-mda Management Stand Alone Add-on Includes information
Discussion and for the section of
Analysis then annual report
where the company’s
management
provides analysis on
results of operations,
financial position and
other issues.
usfr-mr Management Stand Alone Add-on Information
Report 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- SEC Officers Stand Alone Add-on Information
cert Certification contained in the
Officers Certification
report as mandated
by the Sarbanes-
Oxley Act 0f 2002
us-gaap-ci Commercial and Industry Taxonomy This taxonomy is
Industrial Layer intended to provide
Companies 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
Evgenios Skitsanos © 2005 5

6. 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 This taxonomy is
Layer 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.
Evgenios Skitsanos © 2005 6

7. 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
Evgenios Skitsanos © 2005 7

8. 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
Evgenios Skitsanos © 2005 8

9. 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>
Evgenios Skitsanos © 2005 9

10. <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.
Evgenios Skitsanos © 2005 10

11. § 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
Evgenios Skitsanos © 2005 11