The circulation of this Public Working Draft is unrestricted.
Recipients of this draft are invited to submit, with their comments,
notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

1.Goals

The use of ·XBRL, the eXtensible Business Reporting
Language, is increasing worldwide and business people are looking for
information about its utility as well as the way it fits together. The goal of
this document is to help those new to ·XBRL to understand the way that XBRL
International (·XII) materials fit together, what to read and what not to
read. Specifically, this document is intended to provide an overview of the
various documents, processes and ·XML materials published by ·XII work
together.

1.1Intended
audience

This document is primarily intended for a non-technical
audience: preparers, managers, accountants and business people. It is also
important reading for technical managers wishing to bring their teams up to
speed on·XBRL.

·XBRL is a technical language for defining and exchanging
performance information about the financial or business operation of an organisation.
It is built for that purpose exactly, is in use amongst an increasing number of
regulators and market participants, and provides a very high degree of
flexibility. Documentation of the technical foundations is most applicable to
software and tool vendors that intend to develop ·XBRL parsers, validators or
APIs, as well as software professionals that wish to interact with ·XBRL directly,
without an abstraction layer of this sort. It is also important grounding for
software professionals intending to evaluate, acquire and utilise these types
of tools. Their contents are almost never relevant to accountants or reporting
professionals.

Technical advice and interpretation on ·XBRL can be
obtained by anyone via the XBRL-Dev discussion group (http://groups.yahoo.com/group/XBRL-DEV).
The ·XII Specification Working Group (·SWG) monitors this list and is obliged to
provide reasonable assistance through that forum.

The ·SWG does intend to produce both a technical
architecture document (analogous to the World Wide Web Consortium’s Web Architecture
[W3A1]) and a technical roadmap for wider use, and these documents will be
aimed at the technically minded.

The primary building block for ·XBRLis the ·specification.
The ·specification sets out the technical rules for ·XBRLand is aimed primarily
at advanced software professionals that are seeking to build tools that will
directly consume or create ·XBRL documents. Many software
developers will not come directly come into contact with the ·specification because
they will use the library of processors and parsers that others provide and
that simplify ·XBRL
for specific purposes.

·XII publishes the ·specification. For the purpose of this
document we are referring to XBRL 2.1. The XBRL International Steering
Committee (·ISC) has declared that the ·specification will remain stable for at
least two years from any point in time. Therefore, as of this writing, there
will be no subsequent version beyond ·XBRL 2.1 until at least May 2007. The ·SWG
has a tightly defined errata policy that can introduce editions with minor
errata corrections at most every six months. The latest edition of the
specification is dated 2005-04-25 [XBRL].

The ·specification is the most authoritative text in ·XBRL, but
by nature is a complex technical document. Where there is an inconsistency
between the ·specification and another part of the ·XBRL framework, the ·specification prevails.
Clarifications of ·syntax, ·semantics and usage that are set out in the ·specification
appear in other documents published by ·XII. Help for developers that are
using the ·specification is guaranteed to be provided by the ·SWG, including
the ·specification editors.

To assure the interoperability of ·XBRL materials, consistent
interpretation of the ·specification by software developers is essential. The
main control over these interpretations is the ·specification conformance suite.
The conformance suite is a set of computer readable statements about specific
aspects of the ·specification, usually in the form of small samples of ·XBRL that
exercise different “boundary” or “edge” situations and potential
misinterpretations. The conformance suite describes inputs and declares the
required outputs to be produced by software correctly processing those inputs.
By covering different aspects of the ·specification throughout the more than
280 tests, it is possible to ensure that different software products will all process
·XBRL
files in the same way.

Note that statements about compliance with the conformance
suite are self-certifications made by vendors. ·XII does not, at this time, evaluate
vendor software products and declare them “·XBRL Compliant”.

Software applications using ·XBRL can be more rapidly developed when
there is a set of functions that can be used to extract pieces of information
from a set of interrelated ·XBRL documents that all reference each
other. Such functions are particularly valuable when developers need to write
business logic, mathematical formulas, etc. A forthcoming module (subsidiary
to the ·specification) will provide a list of functions, their definitions, and
sample inputs and outputs.

The forthcoming formula linkbase is a new, optional module
of the ·specification that will allow the definition of complex computations,
for validation (evaluating an expression to determine whether it is true or
false) or derivation (evaluating an expression to calculate a new value). This
provides an important building block for business rules that developers will need
to program. Like the ·specification itself, the formula module is something
predominantly of interest to specialist developers that are seeking to support
the operation of this module in their tools which will, themselves, be used by
applications that consume or produce ·XBRL materials.

While the foundation concepts of ·XBRL are mandatory, there
is another layer of guidance materials that ·XII has developed and which
assists the production of ·XBRL software applications (via the Ledger Taxonomy), the
recording of the manner in which individual transactions roll up to journal and
financial performance totals. Modelling rules, however they may be expressed
in documents, provide detailed guidance as to how to use ·XBRL, the
language, to model different kinds of reporting information for different
software applications.

Documents at this level are relevant to software vendors
seeking to produce, extend or consume taxonomies and produce or consume
instance documents, including those basing their offerings on ·XBRL
parsers, validators and APIs. Their principles are relevant to accountants and
reporting professionals that act as ·taxonomy and/or ·instance document authors
and consumers.

It is not mandatory to follow the guidelines set out in
these documents. Rather, their use is something that ·XII strongly encourages.
They are designed to enhance the interoperability of ·XBRLmaterials, and
widespread adherence to them will ensure that it is simpler and easier to
develop software that can produce and consume financial reports in ·XBRL.

·XBRL
can be used for many types of reporting, including internal business
performance reporting. However, the majority of ·XBRLreporting that is being conducted
at present relates to financial statements and similar materials. The
“Financial Reporting Taxonomy Architecture” (·FRTA) and the “Financial
Reporting Instance Standards” (·FRIS) provide guidance on the production of
taxonomies and instance documents respectively. As their names suggest, this
guidance is for financial reporting only; ·FRTA and ·FRIS are focussed on that
type of usage.

Advice about and interpretation of ·FRTA, the General
Ledger ·taxonomy, and other documents at this layer can be obtained through the
XBRL-Dev and XBRL-Public (http://groups.yahoo.com/group/XBRL-Public)
discussion groups. The Working Groups, in particular the editors of ·FRTA and
the General Ledger taxonomy, monitor these lists and are obliged to provide
reasonable assistance through that forum.

Individuals employed by members of ·XII may also access
the XBRL-Domain discussion group (for ·FRTA and ·FRIS topics) and the XBRL-GL
discussion group (http://groups.yahoo.com/group/XBRL-GL)
for General Ledger ·taxonomy topics.

The ·FRTA is a set of rules about the way that taxonomies
should be constructed for maximum interoperability. The document is aimed at
software developers and advanced ·taxonomy developers. Many of the rules can be
incorporated into “·taxonomy builder” software automatically, although others
require a degree of human judgment and interpretation.

The ·FRTA is enforced through the application of the ·Taxonomy
Recognition Process (TRP), which makes conformance with the principles set out
in the guidelines mandatory for those taxonomies that seek to be recognised as
“Approved” by ·XII.

There is no obligation on ·taxonomy authors to seek
Approved status for their work. However, most ·XII ·jurisdictions have
committed to do so. There are incentives (in terms of ease of consumption) for
software developers and ·taxonomy authors who can merely extend an existing ·taxonomy
to conform to FRTA while never considering seeking Approval from ·XII.

Like the ·specification itself, the ·FRTA has an
accompanying conformance suite that provides a computerised representation of
the bulk of the ·FRTA rules. There are some 120 conformance suite tests that
vendors need to apply.

Statements about compliance with the ·FRTA conformance
suite are self-certifications made by vendors. ·XII does not evaluate nor
certify vendor tools for compliance; it does, however, require that two
different implementations pass the conformance suite before ·FRTA itself can be
finalised.

The ·FRIS is a set of rules regarding the way that an ·instance
document should be constructed for maximum interoperability. ·FRIS is
primarily aimed at software developers that are seeking to build offerings that
generate XBRL data, although clearly software developers building offerings
that consume XBRL data benefit from adherence to the standards as well.

·FRIS is subsidiary to ·FRTA, in the sense that ·FRTA conformant
taxonomies will allow the production of ·FRIS conformant ·instance documents.
Unlike the ·FRTA, however, there is no special inducement to ensure that tools
build instances in conformance with ·FRIS. It is likely that common sense will
prevail and ·FRIS will maximise the interoperability of financial reporting
data.

XBRL provides a set of standard roles and arc roles that
may appear in XBRL documents. As XBRL applications emerge, link roles with
common and useful semantics appear. The XBRL Link Role Registry is a public,
online data set that documents these roles and their usage. The link role
registry is the mechanism by which new definitions and rules of usage can be
added to FRTA, and may be expected to have frequent additions.

2.2.6LRR Conformance Suite

The LRR is not a complex database, but does warrant having
its own distinct tests, so that XBRL tools can be identified as to whether they
support online access to the LRR while processing XBRL documents.

The General Ledger ·taxonomy is a fully compliant ·XBRL ·taxonomy
for the specific purpose of recording and exchanging individual transactions
associated with business activities, which, in aggregate will become reporting
concepts. The GL ·taxonomy allows the interoperable exchange of ledger,
sub-ledger and other transactions, as well as the creation of reports based on
the performance information that can be derived from these items in aggregate.
It is a powerful, flexible tool for internal reporting, data consolidation and
e-commerce. http://www.xbrl.org/GLTaxonomy/
is the home page for the GL ·taxonomy, and http://groups.yahoo.com/group/XBRL-GL/
is the ·XII members-only discussion group.

For many users of ·XBRL, the only ·XII materials they will
ever refer to resides on this, the third level of the stack, because they will
be able to rely on the authoritative implementation of the technical rules of ·XBRL by
their chosen software tools.

Their use is not mandatory, merely strongly encouraged.
Once again, the purpose in encouraging the consistent application of the
principles set out in these documents is to maximise the interoperability of ·XBRL
materials that end-users create and consume.

This layer is most relevant to accountants and reporting
professionals seeking to use ·XBRL tools to produce or consume high
quality electronic reports.

Individual ·jurisdictions are increasingly publishing
their own ·taxonomy development guidance materials. These guides typically are
designed to help those involved in the creation of jurisdictional taxonomies as
well as ·extension taxonomies that expand on the base set of definitions that
the ·jurisdiction has created.

The ·XII preparers guide will set out suggestions about
the best way to ·tag data with ·XBRL ·taxonomy concepts and the best way
to extend ·XBRL
taxonomies.

These guidance materials are intended for accountants and
reporting professionals. ·XII strongly encourages their use, but in a range of
circumstances, they will not be applicable, for example where a national
securities regulator sets out its own guidance materials or requirements.

3.Glossary

The information that allows a fact or set of facts to be
understood in relation to other information. Context needs to be identified
inside an ·instance document and typically includes time, organizational
entity, reporting segment, and scenario - whether the fact is budget, actual,
interim, or final.

·DTS

The discoverable ·taxonomy set consists of files that
are related, typically as interlocked modules. Both taxonomies and instance
documents can refer or import other taxonomies so as to re-use concepts that
have been defined elsewhere. A DTS is a mechanism in ·XBRL that facilitates this
re-use.

The ·XII Domain Working Group. This is a (members only)
standing committee that is charged with (1) facilitating the creation and
adoption of taxonomy best practice; and (2) gathering business requirements
for ·XII. It does this through a range of guidance materials as well as a
number of communication and outreach initiatives. Not to be confused with
jurisdictional domain committees, which are often (but not always) set up in a
·jurisdiction to manage the creation of a local GAAP ·taxonomy.

A ·taxonomy that is developed by an organisation to add
corporate-unique concepts or to modify default taxonomy relationship
structures. An extension is often used merely to add a concept to those
available in a GAAP set of disclosures to take account of the particular
circumstances of an organisation. This is generally to allow market
differentiation of a particular market participant. However, extensions are
also used to modify a base ·taxonomy for the purposes of a particular
reporting organization. For instance, a company may choose to use a different
label for a standard GAAP ·taxonomy, or to alter the way that a sub-total is
calculated, to take account of company-specific circumstance. Most companies
involved in reporting to securities regulators will choose to use extensions.

·FRIS

Financial Reporting Instance Standards are a set of
guidelines for the preparation of high quality, highly interoperable ·XBRL ·instance
documents. The majority of FRIS guidelines can be implemented by way of
software that creates instance documents, so is properly regarded as a supporting
set of materials. FRIS conformance can be tested by way of a specialist set
of conformance suite tests.

·FRTA

Financial Reporting ·taxonomy Architecture. A long title
for the ·taxonomy best practices
document created largely by the ·DWG. FRTA aims to ensure that taxonomies
that are built around the world use ·XBRL in some specific ways. This is in
order to improve the interoperability of those taxonomies and to simplify the
software development process for tools that need to process financial
taxonomies. FRTA only relates to Financial Reporting taxonomies. These best
practices are strongly encouraged by way of the ·Taxonomy Recognition Process
(TRP). To reach the recognition level of “Approved”, it is necessary for a ·taxonomy
to be FRTA conformant. FRTA conformance can be tested by way of a specialist
software conformance suite, as well as a range of manual checks.

·IASB

The International Accounting Standards Committee
Foundation. The governing body of the IASB. The IASCF has sponsored a range
of IFRS related ·XBRL activity by both volunteers and staff, including the
creation of the IFRS ·taxonomy.

·IFRS

·instance document

Instance documents are also called ·XBRL Data Documents,
and are sometimes shortened to IDs (this is to be discouraged as “ID” has a
special meaning in the ·specification). Instance documents contain one or
more sets of ·context information that allows the consistent identification
of:

·the organisation(s) that are reporting information

·the date(s) for which information is being reported; and the

·details of any segments (such as the different divisions that
are reporting inside a single organisation) and details of any scenarios
(such as “budget” figures, “forecast” figures and “actual” figures) that are
being used.

Instance documents must also contain one or more unit
identifiers that define the units of measure in use: typically currencies,
but can also be physical or derived measures such as BrakeHorsePower, Meters
and Shares.

Finally, and most importantly, instance documents
contain a “set of facts” that comprise a set of tags that are used by a ·taxonomy,
the data that relate to those tag concepts and the identifiers that place the
information in context.

·ISC

The International Steering Committee of ·XII. The
governing body, in effect a board of directors, with membership elected by ·jurisdictions
(for Jurisdictional seats) and the ·ISC itself for “at large”
representatives.

·jurisdiction

Self-governed, generally country-specific not-for-profit
organization, recognised as the peak ·XBRL authority in that area by ·XII by
way of vote of the ·ISC. Jurisdictions (for a list see http://www.xbrl.org/jurisdictions.aspx) must agree
to the XII branding and intellectual
property policies. Jurisdictions bring together a diverse range of
organisations, from report preparers through to software vendors, intermediaries,
accountants, accounting organizations and official bodies, such as regulators
and accounting standards setters. Since some of these organisations compete
with each other, it is necessary for a suitable neutrally regarded
facilitator to simplify the operation of the jurisdiction. Jurisdictions can
be not-for-profit companies, unincorporated bodies, or simply subordinate
committees or working groups of the facilitator. Jurisdictions act to promote
and facilitate adoption in their area, including by developing relevant
country or industry taxonomies. At the time of writing, the ·IASCF was unique
in not representing a country. This situation comes about by way of its
supra-national characteristics.

The Link Role Registry, a
publicly accessible database that allows advanced users of XBRL to define new
types of relationships between reporting terms [LRR].

·period

The date or time to which a fact in an ·instance
document relates. It can be a point in time (e.g., December 31, 2002) which
is referred to as an “instant” but is also known as a “stock” figure amongst
some reporting communities (especially statistics). Alternatively a period
can be referred to as a “duration” which is a reporting period that extends
over a known time (e.g., the 12 month period ending December 31, 2002). Statisticians
refer to this second type of period as a “flow”.

·semantics

The meaning of an expression. The semantics of the
various parts of ·XBRL itself are defined in the ·specification, but this is
unlikely to be of interest to most end-users. Users of ·XBRL can create their
own semantics in at least two ways. The creation of taxonomies by defining
reporting terms and the way that they relate to each other is the most common
way that ·XBRL allows the creation of comprehensive meanings. However, where
it is possible to extend the ·XBRL itself (for instance by creating a new
type of relationship in the ·LRR) it is necessary to define the meaning of
that relationship.

The technical set of rules that governs the syntax
and fundamental semantics of all ·XBRL materials, both the
definitions that create ·XBRL dictionaries or taxonomies and the
data, or instance documents. This is the main
intellectual property of ·XII.

The ·XII Specification Working Group. This ·XII members-only
working group maintains the ·specification and develops foundation-level
modules and participates in the development of modelling rule-level
documentation.

·syntax

The structure of a language, according to a set of
rules. The syntax of ·XBRL is defined by the ·specification, as well as a
number of other ·XML specifications, including several important W3C standards: XML Schema, Xlink and Xpath.

·stylesheet

Another (less precise) term for an ·element.
"Tagging" means to associate appropriate elements with the concepts
in a business report.

·taxonomist

A professional ·taxonomy developer, concerned, primarily
with the logical organisation of reporting concepts that exist in a
particular domain, whether that be at the level of group internal reporting,
external corporate reporting, the capture and definition of industry key
performance indicia, or an accounting framework promulgated by an accounting
standards setter.

·taxonomy

An organised group of ·XBRL definitions that together
provide meaning to reporting concepts. Taxonomies are used to define
accounting, financial and non-financial reporting terms in a disciplined
manner. Taxonomies are often produced by a central group, for instance the
jurisdictional efforts to develop the US-GAAP, IFRS, UK-GAAP or Canadian GAAP
taxonomies. Taxonomies can equally be developed by a government agency or
regulator to define their specific regulatory information needs. Examples include
the FDIC, FSA, APRA, Danish Companies and Commerce Authority.

Taxonomies comprise several files. Every taxonomy has a
schema document that provides:

·a code for each concept that needs to be communicated

·a data type (such as monetary, string, Boolean)

·some reporting specific information such as whether the time
that a fact is to be reported should be measured as an “instant” (a moment in
time such as “31 December 2005”) or “duration” (a period in which some
activity has been measured, such as the period commencing 1 January 2005 and
ending 31 December 2005”); and

·sometimes certain accounting specific information such as
whether a monetary item should be considered to be a natural credit balance
or natural debit balance.

Taxonomies also contain several linkbases. Linkbases are
organising files that provide various types of information that can be used
to define concepts. The usual linkbases are:

·a label linkbase that provides a caption or label for each
concept, in one or more languages. Special labels for verbose descriptions of
a concept can also be defined in this file.

·a reference linkbase that provides a link from a concept to
authoritative literature that defines it, such as an accounting standard or
regulatory standard.

·a presentation linkbase that provides a default order for a
group of concepts

·a calculation linkbase that provides a default way of
calculating totals and sub-totals for related concepts that have the same
context

·a definition linkbase that describes certain special attributes
of reporting facts, such as equivalence between two concepts.

Shortly, ·XII will publish another type of linkbase
specification – a Formula Linkbase that allows sophisticated mathematical and
logical operations to be carried out on taxonomy concepts, so as to allow the
creation of validation and derivation rules.

·Taxonomy
Recognition Process (TRP)

The TRP is a set of
policies that are applied by XII around the recognition of taxonomies at two
levels:

Acknowledged

Requires that the ·taxonomy is ·XBRL valid, is endorsed
by the body that has developed, is freely accessible (that is, without
royalty payment and without any other restriction), and has been documented
in accordance with the requirements set out in the TRP. Acknowledged
taxonomies can be in use, or they can be under development on their way to
eventual recognition as Approved.

Approved

Requires that the ·taxonomy be acknowledged and ·FRTA conformant.
Approved taxonomies must have been held open for public comment for at least
a 45 day period. Additional documentation requirements include the provision
of at least 2 sample ·instance documents.

·tuple

A set of related facts that need to be expressed and
read together. It can best be thought of as a row in a table. Tuples are defined
in taxonomies and used in instance documents for exactly that.

There is no such certification at this time. ·XII has
not yet produced any sort of test programme or compliance “Kite mark”.
Vendors are able to advise whether or not their tools are able to process the
·specification, ·FRTA or ·FRIS conformance suites, but this is
self-certification and is not endorsed by ·XII.

XBRL International Incorporated. The
not-for-profit global consortium, based in New York, that developed and
manages the base ·XBRL technology and through its member jurisdictions
facilitates the creation of ·XBRL taxonomies.

Appendix B.Intellectual Property Status

This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, such as by removing the copyright notice or references to XBRL
International or XBRL organizations, except as required to translate it into
languages other than English. Members of XBRL International agree to grant
certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is
provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the
possibility that compliance with or adoption of XBRL International
specifications may require use of an invention covered by patent rights. XBRL
International shall not be responsible for identifying patents for which a
license may be required by any XBRL International specification, or for
conducting legal inquiries into the legal validity or scope of those patents
that are brought to its attention. XBRL International specifications are
prospective and advisory only. Prospective users are responsible for protecting
themselves against liability for infringement of patents. XBRL International takes
no position regarding the validity or scope of any intellectual property or
other rights that might be claimed to pertain to the implementation or use of
the technology described in this document or the extent to which any license
under such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. Members of XBRL
International agree to grant certain licenses under the XBRL International
Intellectual Property Policy (www.xbrl.org/legal).

The members of the XBRL Product Development Team provided helpful
comments on each draft and revision. Colm O hAonghusa (EuroReg Consulting)
provided editorial comments. The original concept is loosely based on the
“House of GAAP” [HG].

This appendix contains a list of the errata that have been
incorporated into this document. This represents all those errata corrections
that have been approved by the XBRL International Product Development Team
(PDT) up to and including 2005-05-17. Hyperlinks to
relevant e-mail threads may only be followed by those who have access to the
relevant mailing lists. Access to internal XBRL mailing lists is restricted to
members of XBRL International Inc.