Chapter 14-understanding andusingxbrl-dimensions

FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01)

14. Understanding and Using XBRL
Dimensions12
[This section is a DRAFT until the XBRL Dimensions specification is released,
which is projected for May 2006. This version of the document follows the XBRL
Dimensions 1.0 Candidate Recommendation dated 2005-12-31. Also, the
Aggregator-Contributor Specification (basically the calculation stuff which is still
an internal working draft) will likely be released after May, no real idea when.]
This section explains XBRL Dimensions (which includes the Aggregator-
Contributor Specification; when XBRL Dimensions is stated, that includes the
Aggregator-Contributor Specification) in terms of how dimensions are used in
financial reporting and how dimensions are expressed using XBRL. Dimension is
not an accounting term, but rather an IT technical term. However, dimensions
are used in financial reporting. Other technical terms relating to dimensions
might be multidimensional analysis, hypercubes or cube, measure, OLAP, etc.
These technical terms do relate to financial reporting, but in financial reporting
terms such as "drill down" and "pivot table" and "line item" are used. Here we
will try and reconcile the technical terms and the financial reporting terms relating
to dimensions as they relate to XBRL.
A common form of dimension in financial reporting is the segmental breakdown.
Dimensions are used in both external and internal financial reporting. Some
examples of dimensions include:
• A group and the business segments and/or geographic segments of a
group,
• A class of sales and the breakdown of that class of sales by product or by
region,
• A breakdown of the components of profit and loss by the continuing and
discontinuing portions,
• A comparison of the "actual", "budgeted", and the "variance" between the
actual and budgeted figures.
There are many other use cases for XBRL Dimensions, but the examples above
should provide a grounding in the basic ideas of what is intended to be covered
by the XBRL Dimensions specification, and therefore what we will cover here.

14.1. Brief Explanation of Multidimensional Analysis
This section endeavors to briefly explain multidimensional analysis. If one does
not understand multidimensional analysis concepts, understanding XBRL
dimensions is far more difficult and their need and value will be harder to see.
The following is a definition of multidimensional analysis (http://en.wikipedia.org/
wiki/Multidimensional_analysis):
In statistics, econometrics, and related fields, multidimensional analysis is a
data analysis process that groups data into two basic categories: data
dimensions and measurements.
Fundamentally, multidimensional analysis is about "slicing and dicing" data. To
do this effectively, the dimensions need to be expressed and the relations
between the dimensions need to be expressed.

© 2006 UBmatrix, Inc 383


14.1.1. Simple Use Case
A simple use case will help explain the components of multidimensional analysis.
We will explain the fundamentals of XBRL dimensions using a simple use case.
Consider the following analysis:

The analysis above shows a breakdown of sales by product, with a further
breakdown by region; and another breakdown by region, with a further
breakdown by product. Note that the "Grand Total" of both sections of the
analysis are the same.
There is only one measure (or primary item) in this use case, "Sales". There
are several dimensions: region, product and period. The period is somewhat of
a special type of dimension, basically everyone uses this dimension. All of the
data in the above use case is expressed in Euros. So, this is also somewhat of a
dimension, in this case it is static, meaning it never changes. For example, sales
could be presented also in US Dollars.



Domain members of the regions dimension are: US and Canada, Europe, Asia,
and Other Regions. Members of the products dimension are: consumer health,
generics, pharmaceuticals, and other.

14.1.2. Pivot Tables
The analysis above is presented "on paper"; it is static and hard to change. The
analysis can be presented in another way, the pivot table, which allows a user to
dynamically "pivot" the data across dimensions. Many business people are
familiar with the "pivot table". Take a look at the screen shot of a Microsoft Excel
pivot table which expresses the data shown above:

The pivot table looks slightly different than the actual printed analysis due to the
auto-formatting of the pivot table. If you note the grand totals, you can see that
the data is the same, only presented slightly differently. You have, again, a
breakdown of sales by product, then by region for the periods 2001, 2002, and
2003. The nice thing about pivot tables is that you can easily "pivot" the data to
show it by region, by product, as is shown below: (All the data is for the entity
"Sample Company" and the data is in Euros.)



While it is difficult to get the full experience of a pivot table using static paper as
we need to do here, the value is that data can be "pivoted" across different
dimensions, presenting the data in different ways to meet different needs. The
dimensions we see here are the region and product; but also the period is a
dimension, the entity is a dimension and the concept "sales" is also a dimension.
Some people view the units to be a dimension, others do not. Here, as
everything is shown in one set of units, we don’t really consider the units a
dimension.

14.1.3. Cubes/Multidimensional Analysis
While data can be presented on paper which is static or using an Excel pivot table
which is dynamic; we will now look at a more abstract for of what is going on.
Consider the diagram below:

Sales
2001 2002 2003
Other
Consumer Health All Regions
Generics
Pharmaceutical
All Products US and Canada

Europe

Asia

Other

The diagram, called "Sales", is an abstraction which will be used to explain some
concepts. The "cube" is a common way of looking at multidimensional
information. You may recall from school that there are three axes being shown
and are commonly referred to as the "X" axis (along the bottom), the "Y" axis
(along the left side), and the "Z" axis (front to back). In the cube above; the X
axis is the periods 2001, 2002, and 2003; they Y axis are the regions "All
Regions", "US and Canada", "Europe", etc.; and the Z axis is products such as
"All Products", "Pharmaceuticals", "Generics", etc.
A cube simply allows you to visually comprehend the relationship between the
data, it is only an abstraction. If you were to introduce more axes, you would
need more "dimensions" which would be hard to express in a graphic. As such,
sometimes dimensions are "locked" or held constant to make data fit into an
understandable cube form. In this case, the entity and units are being held
constant.
The large cube can be broken down into smaller cubes. Each smaller cube is an
intersection between a period, a region, and a product for the concept "Sales".
The shaded (blue) above represents sales for the period 2002, the product
pharmaceuticals, for all regions. That "cell" might be expressed by a "fact value"
in an XBRL instance document. That fact value would have a context which
indicates the entity, period, region, and product.
Below is a screenshot of what the actual data might look like:



The data above has had all its presentation information removed, this is what the
data might look like in a database. Note that no total information exists in the
data. Totals are computed "on the fly" by summing the data in various ways.
Data in this format is very flexible, allowing it to be "pivoted" in, say, an Excel
pivot table; showing products by regions by product; etc.
But to express the information as desired, certain relationships, which you may
take for granted if you understand the information must be expressed.
Computers do not intuitively understand this information or semantic meaning.
But if computers COULD understand these relationships, powerful and useful
applications can be built which take advantage of the understanding of this
meaning.

14.1.4. Enter XBRL Dimensions
XBRL Dimensions does just that, allows a computer application to understand
these sorts of relationships. And not only does XBRL Dimensions express this
information; it expresses dimensional information using a global standard which
will eventually be transferable across different software applications. Currently
there are software products which express this type of information, but they use
proprietary methods.
XBRL Dimensions expresses semantic meaning relating to the relationships
between information. For example:



• Indicating that "Total All Products" is the total of all products, and the
product breakdown includes "Pharmaceuticals", "Generics", "Consumer
Health" and "Other".
• Indicating that "Total All Regions" is the total of all regions, and the region
breakdown includes "US and Canada", "Europe", "Asia", and "Other".
• This breakdown is appropriately used for "Sales", but it might not be
appropriate for "Income Tax Expense" which applies only to the Group as
a whole.
So, the above hopefully leaves you with an understanding of some of the basic
concepts of dimensions and helps you see some of the basics of what XBRL
Dimensions are intended to achieve; fundamentally to express relationships.

14.1.5. XBRL Dimensions Features/Requirements
Above a fairly simple example is shown to help explain the basis of XBRL
dimensions. But, there are a few things which should be considered in terms of
multidimensional analysis type features/requirements which are the realities of
business reporting. Not all users demand all of these features/requirements; but
others do.
XBRL Dimensions does not necessarily support all required features or
functionality, but the features it does support are very robust. This robust set of
features can make XBRL Dimensions daunting to comprehend.
The following provides insight as to some of the features which may be required
to effectively express semantic meaning underlying your business data. Still
considering the cube diagram shown above:
• What if information is not required (or should not be provided) for one of
the "cells" of the cube. There needs to be a way to exclude the possibility
of expressing the value for a specific "cell" in the cube. Those "gray
boxes" in a table of information need to be provided for.
• What if the list of dimension members were quite large or possibly not
known (you know that there is a list, but users may have a different list).
There is a need for dimensions to be explicit (such as the explicit lists
above for products and regions) or implicitly when the list is quite long or
not known.
• Sometimes the dimensions may have unique combinations of
relationships. For example, "use a member of this domain OR this
domain, but not both" or "any of the following is acceptable".
• Domain members can be related in different ways. Sometimes there are
calculation relationships between domain members, other times there are
not. The calculations may be positive or negative.
• Hypercubes may be nested.
• Multiple languages, extensibility of dimensions information, assigning
references to dimensional information, assigning a presentation structure
to dimensional information, etc.
This gives you a general idea of the use cases that XBRL dimensions are trying to
provide for.



14.2. Overview of XBRL Dimensions
XBRL Dimensions specification (and again, as a reminder this includes the
Aggregator-Contributor Specification) is created by XBRL International. XBRL
Dimensions is a module of XBRL 2.1; it provides optional incremental functionality
to XBRL 2.1. XBRL Dimensions is a global standard way of expressing
multidimensional information which may exist in business information. This
specification allows for the communication of this semantic information, using a
global standard, so that these relations can be understood by computer
applications.
From an XBRL perspective, what dimensions facilitate is the ability to express
relationships between XBRL contexts. XBRL 2.1 calculations are limited in that
calculations can only be expressed and therefore validated within the same
context. Using XBRL Dimensions and the Aggregator-Contributor specification,
however, relations can be expressed across contexts. XBRL Dimensional
information will also be used by XBRL Formulas (business rules).

14.2.1. Workflow/Process
Dimensional information is expressed using an XBRL taxonomy which has been
extended by the XBRL Dimensions schema (xbrldt-2005.xsd) to support features
of the XBRL dimensions specification. Within the XBRL taxonomy the schema
defines concepts and definition links and calculation links express dimensional
relationships.
Presentation links, labels, references and other features can also be used with
this other dimensional information, but none of these are changed by the XBRL
Dimensions specification.
The goal in expressing relationships is basically to provide continuity between the
building blocks used to construct dimensions. Note that each of the building
blocks will be explained later. The building blocks of dimensions are:
• Primary items
• Hypercubes
• Dimensions
• Domains
• Domain members
The dimensional information expressed in taxonomies is used within XBRL
instance documents which are extended by the dimensional schema for instances
(xbrldi-2005.xsd). That schema basically specifies how dimensional information
is to be expressed within the scenario or segment element of an XBRL instance
document.
The aggregator-contributor calculation arcrole is specified by the Aggregator-
Contributor Specification (xbrlta-2005.xsd). It specifies calculation relations
between domain members.
An XBRL processor which supports XBRL Dimensions can then use this additional
information provided in taxonomies and instance documents to perform additional
processing expressed by the dimensional information. An XBRL processor which
does not support dimensions will still be able to read the XBRL taxonomies and
instance documents (they will still be XBRL valid), however, as the application
does not understand the XBRL Dimensions specification, that application will not
know what the information means and will ignore that information. The main
point here is that XBRL taxonomies and instance document with dimensional



information are still XBRL 2.1 valid, and dimensional information can either be
used or ignored.
Again, dimensions or multidimensional analysis is not unique to XBRL or to
business reporting, but rather has far broader use. The XBRL Dimensions
specification simply is XBRL's way of expressing multidimensional type
information in a global standard way. It does not define new concepts relating to
multidimensional analysis or change them; it simply expresses them in a
standard way.
And don’t get hung up on syntax. The most important feature is the expressing
of the relationships, the syntax will some day be irrelevant altogether, when good
software hides the syntax and lets users achieve what they need to achieve.
The following is a graphical representation of the components of XBRL Dimensions
and relationships as they relate to explicit dimensions:

Primary Item
do

- MAY be any number of primary items
m arc
arcrole

ai ro
has-h ll, notAll}

n- le
m
em
be
yperc
{a

r

Primary Item
ube

- MUST be first child in collection of primary items
Hypercube
hy
pe
rcu arcro
be le
-di
me
ns
io n

- MUST be abstract
Dimension - MAY be summable, or not
Declaration
dim a
en rcro
sio le
n-d
om
ina

- MUST specify targetRole to actual domain
Effective Domain
do ar
ma cro
in- le
me
mb
er

- MAY be any number of
Domain Member(s) domain members

The following sections will explain these terms and the relationships between the
terms shown in the graphic above, this graphic is just your first exposure to the
big picture of how XBRL Dimensions work. Examples will also be provided which
walk you through the use of these components so you can effectively express
relationships you wish to express in taxonomies, and use that information
correctly within XBRL instance documents.



14.2.2. Dimensions Example 1 – Sales (Not Modular)
With this document a set of sample XBRL files is provided which show how
dimensional information looks in its XML form. Below, we provide copies of the
XSD file, the definition linkbase, the calculation linkbase, and an instance
document to show what the XBRL looks like. For more technical users, it helps
make understanding dimensions easier. These files can be reverse engineered to
learn how to build this dimension information. We will also point out a few things
to note about each of these files. For those not comfortable with angle brackets,
simply ignore that information if you so choose.
Further we want to point out that the first sample we will look at is a single
taxonomy (XSD) file (Company.xsd). It is not modularized to maximize reuse in
any way; it is created as one file to make understanding the information in the
files a bit easier. When we actually build and then use dimensional information
later, we will modularize the taxonomies as they will likely exist in real life. The
single file simply helps see how things fit together.

14.2.2.1. Explanation of Sample
The sample taxonomy and instance document express the dimensional
information shown in the diagram below (see file Sales-Pattern.xls or Sales-
Pattern.pdf):

Basically, what is shown is a breakdown of sales by segment and by region for
three periods.

14.2.2.2. Sample's Taxonomy File (XSD)
The following is a screen shot of what the taxonomy for the sample might look in
an XBRL taxonomy editor. Note the presentation, calculation, and definition
relationship views on the top and the list of elements on the bottom of the
screenshot.


Below is the XSD file for the sample (Company.xsd):
<?xml version="1.0" encoding="utf-8"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:xbrli="http://www.xbrl.org/2003/instance"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:company="http://www.SampleCompany.com/Company"
xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
targetNamespace="http://www.SampleCompany.com/Company"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<annotation>
<appinfo>
<link:linkbaseRef xlink:type="simple" xlink:href="Company-label.xml"
xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef"
xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:title="Label Links, all" />

<link:linkbaseRef xlink:type="simple" xlink:href="Company-definition.xml"
xlink:role="http://www.xbrl.org/2003/role/definitionLinkbaseRef"
xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:title="Definition Links, all" />
<link:linkbaseRef xlink:type="simple" xlink:href="Company-presentation.xml"
xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef"
xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:title="Presentation Links, all" />
<link:linkbaseRef xlink:type="simple" xlink:href="Company-calculation.xml"
xlink:role="http://www.xbrl.org/2003/role/calculationLinkbaseRef"
xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:title="Calculation Links, all" />
</appinfo>
</annotation>

<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-
12-31.xsd" />
<import namespace="http://xbrl.org/2005/xbrldt" schemaLocation="../xbrldt-2005.xsd" />


<element id="company_Sales" name="Sales" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"
xbrli:periodType="duration" nillable="true" />


<element id="company_ByProductPlaceholder" name="ByProductPlaceholder" type="xbrli:stringItemType"
substitutionGroup="xbrldt:dimensionItem" xbrli:periodType="duration" abstract="true" nillable="true" />
<element id="company_ByRegionPlaceholder" name="ByRegionPlaceholder" type="xbrli:stringItemType"
substitutionGroup="xbrldt:dimensionItem" xbrli:periodType="duration" abstract="true" nillable="true" />


<element id="company_CompanyHypercube" name="CompanyHypercube" type="xbrli:stringItemType"
substitutionGroup="xbrldt:hypercubeItem" xbrli:periodType="duration" abstract="true" nillable="true" />


<element id="company_AllProducts" name="AllProducts" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"

<element id="company_ConsumerHealthSegment" name="ConsumerHealthSegment" type="xbrli:monetaryItemType"
substitutionGroup="xbrli:item" xbrli:periodType="duration" nillable="true" />
<element id="company_GenericsSegment" name="GenericsSegment" type="xbrli:monetaryItemType"
<element id="company_PharmaceuticalsSegment" name="PharmaceuticalsSegment" type="xbrli:monetaryItemType"
<element id="company_OtherSegments" name="OtherSegments" type="xbrli:monetaryItemType"


<element id="company_AllRegions" name="AllRegions" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"
<element id="company_AsiaRegion" name="AsiaRegion" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"
<element id="company_EuropeRegion" name="EuropeRegion" type="xbrli:monetaryItemType"
<element id="company_USAndCanadaRegion" name="USAndCanadaRegion" type="xbrli:monetaryItemType"
<element id="company_OtherRegions" name="OtherRegions" type="xbrli:monetaryItemType"
</schema>

There are two main things to note about the XSD file above. First, note the
import of the dimensions taxonomy schema. Second, note the use of the
substitution group xbrldt:DimensionItem and xbrldt:HypercubeItem. These will be
explained below. The remainder of the schema file should be familiar to someone
who understands XBRL.

14.2.2.3. Sample's Definition Linkbase
Below is the definition linkbase for the sample (Company-definition.xml):
<linkbase xmlns="http://www.xbrl.org/2003/linkbase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
xmlns:xbrldta="http://xbrl.org/2005/xbrldta" xsi:schemaLocation=" http://www.xbrl.org/2003/linkbase
http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd http://xbrl.org/2005/xbrldt ../xbrldt-2005.xsd
http://xbrl.org/2005/xbrldta ../xbrldta-2005.xsd">
<arcroleRef xlink:type="simple" xlink:href="../xbrldt-2005.xsd#hypercube-dimension"
arcroleURI="http://xbrl.org/int/dim/arcrole/hypercube-dimension" />
<arcroleRef xlink:type="simple" xlink:href="../xbrldt-2005.xsd#dimension-domain"
arcroleURI="http://xbrl.org/int/dim/arcrole/dimension-domain" />
<arcroleRef xlink:type="simple" xlink:href="../xbrldt-2005.xsd#domain-member"
arcroleURI="http://xbrl.org/int/dim/arcrole/domain-member" />
<arcroleRef xlink:type="simple" xlink:href="../xbrldt-2005.xsd#all"
arcroleURI="http://xbrl.org/int/dim/arcrole/all" />
<definitionLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link">
<loc xlink:type="locator" xlink:href="Company.xsd#company_Sales" xlink:label="company_Sales" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_CompanyHypercube"
xlink:label="company_CompanyHypercube" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_ByRegionPlaceholder"
xlink:label="company_ByRegionPlaceholder" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_AllRegions" xlink:label="company_AllRegions" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_USAndCanadaRegion"
xlink:label="company_USAndCanadaRegion" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_EuropeRegion" xlink:label="company_EuropeRegion" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_AsiaRegion" xlink:label="company_AsiaRegion" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_OtherRegions" xlink:label="company_OtherRegions" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_ByProductPlaceholder"
xlink:label="company_ByProductPlaceholder" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_AllProducts" xlink:label="company_AllProducts" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_PharmaceuticalsSegment"
xlink:label="company_PharmaceuticalsSegment" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_GenericsSegment" xlink:label="company_GenericsSegment"
/>
<loc xlink:type="locator" xlink:href="Company.xsd#company_ConsumerHealthSegment"
xlink:label="company_ConsumerHealthSegment" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_OtherSegments" xlink:label="company_OtherSegments" />

<definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/all" xlink:from="company_Sales"
xlink:to="company_CompanyHypercube" order="1" use="optional" xbrldt:targetRole="http://www.xbrl.org/2003/role/link"
xbrldt:contextElement="scenario" xbrldta:summable="true" />
<definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/hypercube-dimension"
xlink:from="company_CompanyHypercube" xlink:to="company_ByRegionPlaceholder" order="1" use="optional"
xbrldta:summable="true" />
<definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/dimension-domain"
xlink:from="company_ByRegionPlaceholder" xlink:to="company_AllRegions" order="1" use="optional"
xbrldt:targetRole="http://www.xbrl.org/2003/role/link" xbrldt:usable="true" />
<definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member"
xlink:from="company_AllRegions" xlink:to="company_USAndCanadaRegion" order="1" use="optional" xbrldt:usable="true"


/>
xlink:from="company_AllRegions" xlink:to="company_EuropeRegion" order="2" use="optional" xbrldt:usable="true" />
xlink:from="company_AllRegions" xlink:to="company_AsiaRegion" order="3" use="optional" xbrldt:usable="true" />
xlink:from="company_AllRegions" xlink:to="company_OtherRegions" order="4" use="optional" xbrldt:usable="true" />
<definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/hypercube-dimension"
xlink:from="company_CompanyHypercube" xlink:to="company_ByProductPlaceholder" order="2" use="optional"
xbrldta:summable="true" />
<definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/dimension-domain"
xlink:from="company_ByProductPlaceholder" xlink:to="company_AllProducts" order="1" use="optional"
xbrldt:targetRole="http://www.xbrl.org/2003/role/link" xbrldt:usable="true" />
xlink:from="company_AllProducts" xlink:to="company_PharmaceuticalsSegment" order="1" use="optional"
xbrldt:usable="true" />
xlink:from="company_AllProducts" xlink:to="company_GenericsSegment" order="2" use="optional" xbrldt:usable="true" />
xlink:from="company_AllProducts" xlink:to="company_ConsumerHealthSegment" order="3" use="optional"
xbrldt:usable="true" />
xlink:from="company_AllProducts" xlink:to="company_OtherSegments" order="4" use="optional" xbrldt:usable="true" />
</definitionLink>
</linkbase>

The thing to note relating to the definition linkbase is the definition and use of
several new arcroles and attributes defined by the XBRL Dimensions taxonomy
which are used on those arcs.

14.2.2.4. Sample's Calculation Linkbase
Below is the calculation linkbase for the sample (Company-calculation.xml):
<linkbase
xmlns="http://www.xbrl.org/2003/linkbase"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=" http://www.xbrl.org/2003/linkbase http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd">
<arcroleRef xlink:type="simple" xlink:href="../xbrldta-2005.xsd#aggregator-contributor"
arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor" />
<calculationLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link">
<loc xlink:type="locator" xlink:href="Company.xsd#company_AllProducts" xlink:label="company_AllProducts" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_PharmaceuticalsSegment"
xlink:label="company_PharmaceuticalsSegment" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_ConsumerHealthSegment"
xlink:label="company_ConsumerHealthSegment" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_GenericsSegment" xlink:label="company_GenericsSegment"
/>
<loc xlink:type="locator" xlink:href="Company.xsd#company_OtherSegments" xlink:label="company_OtherSegments" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_AllRegions" xlink:label="company_AllRegions" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_USAndCanadaRegion"
xlink:label="company_USAndCanadaRegion" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_EuropeRegion" xlink:label="company_EuropeRegion" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_AsiaRegion" xlink:label="company_AsiaRegion" />
<loc xlink:type="locator" xlink:href="Company.xsd#company_OtherRegions" xlink:label="company_OtherRegions" />
<calculationArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/aggregator-contributor"
xlink:from="company_AllProducts" xlink:to="company_PharmaceuticalsSegment" order="1" weight="1" use="optional" />
xlink:from="company_AllProducts" xlink:to="company_ConsumerHealthSegment" order="2" weight="1" use="optional" />
xlink:from="company_AllProducts" xlink:to="company_GenericsSegment" order="3" weight="1" use="optional" />
xlink:from="company_AllProducts" xlink:to="company_OtherSegments" order="4" weight="1" use="optional" />
xlink:from="company_AllRegions" xlink:to="company_USAndCanadaRegion" order="1" weight="1" use="optional" />
xlink:from="company_AllRegions" xlink:to="company_EuropeRegion" order="2" weight="1" use="optional" />
xlink:from="company_AllRegions" xlink:to="company_AsiaRegion" order="3" weight="1" use="optional" />
xlink:from="company_AllRegions" xlink:to="company_OtherRegions" order="4" weight="1" use="optional" />
</calculationLink>
</linkbase>

Note that the calculation linkbase uses "aggregator-contributor" arcroles rather
than "summation-item" arcroles on calculation arcs.


14.2.2.5. Sample's Presentation and Labels Linkbases
These files are the same as any other XBRL presentation and label linkbase,
therefore they are not shown.

14.2.2.6. Sample's Instance document
Below is the instance document for the sample (Sample-Instance.xml):

<xbrl xmlns="http://www.xbrl.org/2003/instance"
xmlns:xbrli="http://www.xbrl.org/2003/instance"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xbrldi="http://xbrl.org/2005/xbrldi"
xmlns:company="http://www.SampleCompany.com/Company"
xmlns:iso4217="http://www.xbrl.org/2003/iso4217"
xsi:schemaLocation="http://xbrl.org/2005/xbrldi xbrldi-2005.xsd">

<link:schemaRef xlink:type="simple" xlink:href="Company.xsd" />


<context id="D-2003-All">
<entity>
<identifier scheme="http://www.SampleCompany.com">SAMP</identifier>
</entity>
<period>
<startDate>2003-01-01</startDate>
<endDate>2003-12-31</endDate>
</period>
<scenario>
<xbrldi:explicitMember xlink:type="simple"
xlink:href="Company.xsd#company_ByRegionPlaceholder">company:AllRegions</xbrldi:explicitMember>
xlink:href="Company.xsd#company_ByProductPlaceholder">company:AllProducts</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-Pharm">
<entity>
</entity>
<period>
</period>
<scenario>

xlink:href="Company.xsd#company_ByProductPlaceholder">company:PharmaceuticalsSegment</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-Gen">
<entity>
</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByProductPlaceholder">company:GenericsSegment</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-ConHealth">
<entity>

</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByProductPlaceholder">company:ConsumerHealthSegment</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-OtherSeg">
<entity>
</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByProductPlaceholder">company:OtherSegments</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>

</scenario>
</context>


<context id="D-2003-US">
<entity>
</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByRegionPlaceholder">company:USAndCanadaRegion</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-Europe">
<entity>
</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByRegionPlaceholder">company:EuropeRegion</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>

</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-Asia">
<entity>
</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByRegionPlaceholder">company:AsiaRegion</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>


<context id="D-2003-OtherRegions">
<entity>
</entity>
<period>
</period>
<scenario>
xlink:href="Company.xsd#company_ByRegionPlaceholder">company:OtherRegions</xbrldi:explicitMember>
</scenario>
</context>
<entity>
</entity>
<period>
</period>

<scenario>
</scenario>
</context>
<entity>
</entity>
<period>
</period>
<scenario>
</scenario>
</context>

<unit id="U-Monetary">
<measure>iso4217:EUR</measure>
</unit>


<company:Sales contextRef="D-2003-All" unitRef="U-Monetary" decimals="INF">32038000</company:Sales>


<company:Sales contextRef="D-2003-Pharm" unitRef="U-Monetary" decimals="INF">20181000</company:Sales>

<company:Sales contextRef="D-2003-Gen" unitRef="U-Monetary" decimals="INF">2433000</company:Sales>

<company:Sales contextRef="D-2003-ConHealth" unitRef="U-Monetary" decimals="INF">6675000</company:Sales>

<company:Sales contextRef="D-2003-OtherSeg" unitRef="U-Monetary" decimals="INF">2749000</company:Sales>


<company:Sales contextRef="D-2003-US" unitRef="U-Monetary" decimals="INF">10214000</company:Sales>

<company:Sales contextRef="D-2003-Europe" unitRef="U-Monetary" decimals="INF">11901000</company:Sales>

<company:Sales contextRef="D-2003-Asia" unitRef="U-Monetary" decimals="INF">5639000</company:Sales>

<company:Sales contextRef="D-2003-OtherRegions" unitRef="U-Monetary" decimals="INF">4284000</company:Sales>

</xbrl>

The primary thing you will notice about the instance document is the large
number of contexts, basically one for each "cell" of data. Also, within the
scenario element you will note the dimension information relating to each
context.

14.2.3. XBRL Dimensions Terminology
Again, dimensions are not unique to XBRL. What XBRL Dimensions do is express
something which is common in business reporting using XBRL in a global standard


way. The syntax used to do this may be new, but what is being expressed is
common to multidimensional analysis.
The following is a summary of terminology which is important to understand in
order to grasp XBRL Dimensions functionality. If you are familiar with
multidimensional analysis, then you likely already understand many or most of
these terms already. If you use Microsoft Excel pivot tables, then you probably
understand these concepts, although you may not explicitly use these specific
terms.
We will define terms so they are meaningful to those understanding
multidimensional analysis, those who understand pivot tables, and those who are
trying to understand XBRL Dimensions.
First, the following are the terms which are used to define the building blocks of
dimensional relations:
Term Explanation
Primary item A primary item are the concepts defined in an XBRL taxonomy
which are part of the xbrli:item substitution group. Tuples are not
allowed in dimensions. Some examples of primary items might be
concepts such as "Sales", "Assets", and "Cash Flows from
Operations".

Hypercube A hypercube is a collection of one or more possible dimensions.
For example the hypercube "Geographical Breakdown" would have
the "Region" dimension. Note that hypercubes are XBRL elements
with the substitution group value of "xbrldt:hypercubeItem".

Dimension A dimension is each different way which a primary item may be
characterized. For example the primary item "Sales" can be
characterized by the dimensions "Region", "Product", etc. A
dimension must have at least one domain. Note that dimensions
are XBRL elements with the substitution group value of
"xbrldt:dimensionItem".

Domain A domain is the set of all domain members which are used to
express a dimension. For example, the "Regions" domain is "Total
for All Regions", "Europe", "USA", "Asia", "Africa", "Australia"
would be a domain.

Domain member A domain member is one of the members of the domain. For
example, for the "Regions" domain, "Europe" would be member of
the domain.

Now we will explain these terms which might be used in a pivot table. A
hypercube is like the pivot table. The dimensions/domains are the things which
are pivoted, and the primary items are the data which is being reported in the
pivot table. The following is this information as it would appear within an Excel
pivot table wizard:



These are other important terms which are important to understand in order to
understand how dimensions work:
Term Explanation
Aggregator The aggregator is the domain member which represents the result
of adding all the other domain members. For example, "Total for
All Regions" is the aggregator of the "Regions" dimension. It is
used to express the sum of the domain members "Europe", "USA",
"Asia", "Africa", "Australia".

Explicit Dimension Dimensions where the domain explicitly defines each possible
member. For example, the "Regions" dimension above is an
explicit dimension as its members; "Europe", "USA", "Asia",
"Africa", "Australia"; are explicitly defined.

Implicit Dimensions Dimensions where, for example, the number of members is
impractically large to explicitly define. For example, the
dimension "Longitude and Latitude" would be a good use for
implicit dimensions as the domain longitude is an infinite number
of numbers between 180 and -180.

all/notAll Composers These composers are used to constrain XBRL contexts so that only
appropriate dimension information can be within a context which
is used on a specific concept.

all – All of the dimensions must be present.
notAll – Negated version of "All"

(These composers work similar to XML Schema composers.)

Note that dimensional information is always expressed within the <scenario> or
<segment> element of an XBRL context. The default, and when in doubt as to
which to use, is the <scenario> element of a context.

14.2.4. Building Blocks
Expressing dimensional information in taxonomies is somewhat like using building
blocks, like the familiar "Lego's" to build what you desire to express. This section
describes these building blocks and what they allow users to express in
taxonomies.



Keep in the back of your mind that at times modularity to allow reuse of
dimensional components is important. However, we are not necessarily going to
build the first basic samples of using dimensions considering modularity as they
make understanding dimensions more difficult.
All the dimensional information in this first example will be constructed in one
XBRL extended link. We will use multiple taxonomies to express this information.
Again, modularity issues are an advanced topic and will not be addressed by us
here.
So, in order to express your dimensional information, the steps which would get
you there, expressed in a logical way would be:
1. Create primary item(s) (tuples are not allowed to be used in dimensions).
2. Create hypercube which will be used to organize and express the
dimensions you wish to express.
a. Create role of all/notAll relation between hypercube and primary
item
b. Specify the ContextElement (<segment> or <scenario>) which will
hold the dimensional information in the instance document.
c. Indicate whether the hypercube is summable
d. Indicate whether the hypercube is closed (can be extended,
optional).
3. Create the dimensions of the hypercube
a. Create arcrole (which may only be hypercube-dimension)
b. Set value of summable attribute to indicate if calculations can be
used in the hypercube
4. Create each domain.
a. Create arcrole (which may only be dimension-domain)
5. Create concepts which will make up the domain members
a. Create arcrole (which may only be domain-member)
b. Express the calculation relationships for domain members
Note that creating the dimension information does not necessarily need to be
performed in the order indicated above, however all the components must be
expressed to correctly express the dimension relationships. If the dimensional
information crosses extended links, the targetRole is used to "point" to the
appropriate extended link.
Building blocks of dimensions are expressed in the form or relations in an XBRL
definition linkbase. The relations (arcs) have different purposes (arcroles). The
different arcroles have different attributes. These building blocks are summarized
in the following table. These building blocks are shown by arcrole with the
attributes of the arcrole shown below each arcrole:

Building block Building Block Type Explanation
Has-Hypercube arcrole arcrole Takes forms: all, notAll
targetRole Attribute Points to the extended link role
which holds the dimension
information
summable Attribute Is the hypercube summable?
contextElement Attribute Explains which instance element



will hold the dimensions,
<segment> or <scenario>.
Closed Attribute Indicates whether the dimension is
closed.

Dimension-Hypercube arcrole arcrole Connects a dimension to a
hypercube. Requires you to specify
if a hypercube is summable
information
Closed Attribute Indicates whether the dimension is
closed.

Dimension-Domain arcrole arcrole Connects a domain to a dimension
information

Domain-Member arcrole arcrole Connects a domain member to a
domain.
Usable Attribute Indicates if the domain member
may be used in an instance
document.
information
Note that the order, prohibited, required, and priority attributes are not
explained. These XBRL attributes work the same way as prescribed by the XBRL
specification.

14.3. Dimensions Example 2 – Sales (Modular)
In the first example, we explained dimensions to you, we did not build anything.
In this second example, we will actually build the same thing we walked through
in the first example. The only difference is that now we will take a modular
approach to creating the taxonomies. We will walk through creating all aspects of
a taxonomy which expresses one primary concept and dimensions and an
instance document which uses those dimensions. We will focus on dimensions by
reporting only one concept, "Sales", but in multiple dimensions. From an
accountant’s perspective, this can be seen as reporting financial highlights for
only one line item, Sales, with breakdowns of the information by segment and by
product.
This example does not use many of the advanced use cases of dimensions in
order to focus on covering the use case which will be used by the vast majority of
those using dimensions. More advanced features are discussed later in this
document. A full explanation of, and an explanation of how to use, all dimensions
features is beyond the scope of this document.
Whereas the case explained above shows all dimensional information expressed
in one XSD file, this case will show the creation of modular taxonomies. This will
help you get a feel for how this will most likely work in the real world.



14.3.1. Explanation of the Use Case
The following is an explanation of the use case. Note that this use case is similar
to, but not the same as data used when first explaining dimensions. These
differences exist for two reasons. First, it reduces the amount of data required
for the example. Second and more importantly, for financial reporting, it is not
the case that a breakdown by product segment also requires a further breakdown
by region; or that the region breakdown requires a further breakdown by product
segment.
In this case study, a company "Sample Company" reports financial highlights for
"Sales" for three periods, breaking sales down by business segments (or
products) "Pharmaceuticals", "Generics", "Consumer Health" and "Other"
segments. It also breaks sales down by regions including "US and Canada",
"Europe", "Asia" and "Other".
This type of breakdown is very common in IFRS, breaking down segmental
information by business and/or by geographic segment.

Next, we will create the taxonomies and instance document. But first, we will
discuss the data used in this exercise.

14.3.2. Data Used
The following is a summary of the data to be used for this exercise:
Label/Name 2003 2002 2001

Sales 32038000 35805000 32465000

Breakdown by Segment
Pharmaceuticals Segment 20181000 18150000 15275000
Generics Segment 2433000 1973000 1823000
Consumer Health Segment 6675000 6514000 5752000
Other Segments 2749000 9168000 9615000



Total 32038000 35805000 32465000

Breakdown by Region
US and Canada 10214000 12649000 10137000
Europe 11901000 10374000 10396000
Asia 5639000 4371000 3210000
Other Regions 4284000 8411000 8722000
Total 32038000 35805000 32465000

Note that all values are presented in thousands of Euros but actual values are
entered into the instance document.

14.3.3. Steps to Express Relationships in Taxonomies
The following are the steps to build the taxonomies which will be used to express
the dimensional relationships. We will build a simple primary concept taxonomy
which contains only one concept. We will then build two dimensions taxonomies
(product and region) to express the dimensions. We will then hook all this
together in a company taxonomy and build the hypercube and other dimensional
infrastructure to express the relations we desire to express.

14.3.3.1. Primary Taxonomy
The first thing you need to either have or create is the primary taxonomy which
contains the concepts for which data is expressed. Examples of primary
taxonomies would be the IFRS-GP taxonomy or the US GAAP taxonomies.
In this case, our primary taxonomy will be very simple and will contain only one
concept, "Sales". This is a very simple example, but it will serve our needs. To
do this:
1. Create a new taxonomy.
Name Value
NamespacePrefix: ci
NamespaceIdentifier: http://www.UBmatrix.com/Patterns/Sales
Filename: Sales.xsd

2. Add the concept "Sales" which is a monetary data type, a credit, and has a
period type of duration.
Element Name (Auto Data Balance Period
Element Label Created) Type Type Type
Sales Sales Monetary Credit Duration

3. Save the taxonomy. The taxonomy has no presentation, calculation, or
definitions relationships as there is only one concept, therefore no
possibility of a relationship.
So now you have a primary taxonomy containing one concept, "Sales". This
concept is an item which will be used in instance documents to report the value
for sales.

14.3.3.2. Dimensions Taxonomies
The next step is to express the domains which will be used in our dimensions
taxonomy. Our first domain is the products segments. The second domain is



regions. We will create these as separate taxonomies. We will first create the
product segments taxonomy. To do this:
1. Create a new taxonomy using the following information:
Name Value
NamespacePrefix: products
NamespaceIdentifier: http://www.SampleCompany.com/Products
Filename: Products.xsd

We need to import the XBRL Dimensions schema to enable dimensions in this
taxonomy.
2. Add the following concepts to the taxonomy:
All Products AllProducts Monetary Duration
Pharmaceuticals Segment PharmaceuticalsSegment Monetary Duration
Generics Segment GenericsSegment Monetary Duration
Consumer Health Segment ConsumerHealthSegment Monetary Duration
Other Segments OtherSegments Monetary Duration

Note that domains are expressed using a normal XBRL taxonomy. Some of the
information in the taxonomy is not used, such as the period type. The period
type is required, therefore it must be set to something. Setting the period type
to duration does NOT limit the use of the domain on only concepts with duration
type. Some of the information for normal taxonomies is irrelevant for
dimensional taxonomies. But because dimensions taxonomies uses normal XBRL
taxonomies, this is the way it has to be. Down the road, it is likely a
"dimensionType" is created in XBRL to differentiate XBRL items from XBRL
concepts used only for dimensions.
The next task is to express the domain member relationships in the taxonomy
using the definition linkbase.
Element Label Definition arcrole
All Products (none, this is a root concept)
Pharmaceuticals Segment domain-member
Generics Segment domain-member
Consumer Health Segment domain-member
Other Segments domain-member

And finally, we will express the calculation information for the domain. This is
done using the calculation linkbase but with a special calculation arcrole,
"Aggregator-Contributor" which is defined by the XBRL Dimensions specification,
to express the calculation relationships.

Element Label Calculation Relationship Weight
All Products (none, this is a root concept)
Pharmaceuticals Segment aggregator-contributor 1

Generics Segment aggregator-contributor 1

Consumer Health Segment aggregator-contributor 1

Other Segments aggregator-contributor 1

Basically, those are the steps to creating the product segment domain. That
domain has members such as the "Pharmaceuticals Segment", etc. Each of these
members is expressed in the form of a definition relationship with a "domain-
member" arcrole on the definition relation.



When you are done building the presentation, calculation, and definition
linkbases, your taxonomy will look like this:

Save your taxonomy.
Next, we will repeat this process for the regions domain. Below we will provide
all the information you need to build this taxonomy to express these dimensional
relationships but we will not walk through the process, it is the same as the first.
Taxonomy information:
Name Value
NamespacePrefix: regions
NamespaceIdentifier: http://www.SampleCompany.com/regions
Filename: Regions.xsd

We need to import the XBRL Dimensions schema to enable dimensions in this
taxonomy.
Concepts to add:
All Regions AllRegions Monetary Duration
US and Canada Region USAndCanadaRegion Monetary Duration
Europe Region EuropeRegion Monetary Duration
Asia Region AsiaRegion Monetary Duration
Other Regions OtherRegions Monetary Duration

Calculation linkbase information:

Element Label Calculation arcrole Weight
All Regions (none, this is a root concept)
US and Canada Region aggregator-contributor 1

Europe Region aggregator-contributor 1

Asia Region aggregator-contributor 1

Other Regions aggregator-contributor 1

Definition linkbase information:
Element Label Definition arcrole
All Regions (none, this is a root concept)
US and Canada Region domain-member
Europe Region domain-member
Asia Region domain-member
Other Regions domain-member



After entering the concepts and creating the presentation, calculation, and
definition relationships, your regions taxonomy looks like this:

So, you can see that the regions domain looks very similar to the products
domain. Each domain has an aggregator ("All Products" and "All Regions") and
domain members. No new extended links were created for these two
taxonomies. As you can see, so far there is not much of a difference between
creating dimensions taxonomy and a regular XBRL primary taxonomy.

14.3.3.3. Company Taxonomy
Next, we will bring all of the primary taxonomy and domain taxonomies together
and build the infrastructure to express our multi-dimensional relationships which
will be used to validate information contained in our instance document. After all,
being able to validate the information contained in an instance document is the
reason for going through the trouble to express this information in the first place.
To begin, we create another taxonomy which will import the other taxonomies we
created so we can work with them as a set. Then, in that new taxonomy, we will
create the dimensional information. This company taxonomy we will create can
be considered equivalent to an extension taxonomy a company might create.
So, the first step is to create a new taxonomy using the following information:
Name Value
NamespacePrefix: company
NamespaceIdentifier: http://www.SampleCompany.com/Company
Filename: Company.xsd

Next, we will link the previously created taxonomies to the company's taxonomy.
All of the following should be connected to the company taxonomy using XML
Schema import elements in the taxonomy you just created:
• The taxonomy which contains the primary items (or in this case a single
XBRL item concept), "Sales.xsd".
• The taxonomy which expresses the products domain information,
"Products.xsd"
• The taxonomy which expresses the regions domain information,
"Regions.xsd"
• And finally, the XBRL Dimensions schema itself to enable dimensions from
within this taxonomy.
Now, we need to add a few XBRL concepts which we will use in expressing the
dimensional relations. Add these concepts to the "Company.xsd" taxonomy:



Element Label Created) Type Substitution Group Abstract Type Type
Company Hypercube CompanyHypercube String xbrldt:hypercubeItem True Duration
By Product (Placeholder) ByProductPlaceholder String xbrldt:dimensiontem True Duration
By Region (Placeholder) ByRegionPlaceholder String xbrldt:dimensiontem True Duration

Note that each of the three concepts defined above are abstract. These concepts
would never actually appear in an instance document, but rather are used to
organize dimensional information.
Next, we need to create two XBRL extended links which we will use to hold
relations we are going to express. Add the following two extended links to your
"Company.xsd" taxonomy:
Extended link Role Description Used On
http://www.SampleCompany.com/Hypercube Hypercube Definition
http://www.SampleCompany.com/PrimaryConcepts Primary Concepts Definition

What you have thus far is a taxonomy which contains three concepts, two
extended links we will make use of in the definition linkbase, and import elements
which import three taxonomies (two domain definitions and the primary items)
and an import of the XBRL Dimensions schema.
Next, we begin building the dimensional information. In summary, we will do the
following:
• Hook the domains "Products" and "Regions" to the hypercube to explain
the group of dimensions which make up the hypercube.
• Hook the hypercube to the primary items, in this case just one concept
"Sales" to express that this concept has dimensions.
• Do some other wiring to express other details of our dimensional
relationships.
In the following table, the information which will be entered is summarized. Keep
in mind that we will be segregating the information into different extended links
to facilitate reuse. But, this table summarizes the end result of what we will
enter:
Element Label Arcrole Attribute values and other info
Sales
Company Hypercube xbrldt:all summable=true; contextElement=scenario
By Region (Placeholder) hypercube-dimension
All Regions dimension-domain summable=true
US and Canada Region domain-member
European Region domain-member
Asia Region domain-member
Other Regions domain-member
By Product (Placeholder) hypercube-dimension
All Products dimension-domain summable=true
Pharmaceuticals Segment domain-member
Generics Segment domain-member
Consumer Health Segment domain-member
Other Segments domain-member

When default values are used, these attributes are not shown. First we will build
the hypercube. To build the hypercube, we perform the following steps. All this
is achieved in the definition view of the taxonomy:
1. Add the concept named "CompanyHypercube" to the extended link with
the description "Hypercube". This starts your hypercube.



2. Add the concept "ByRegionPlaceholder" as a child of the concept
"CompanyHypercube" using a "hypercube-dimension" arcrole. The
attribute "xbrldt:summable" should be set to "True" as this dimension is
summable. This step adds a necessary placeholder component to the
hypercube so that the regions dimension can be added to your hypercube.
Note that the summable attribute is used to indicate that the hypercube is
intended to be used for dimensional calculations.
3. Add the concept "AllRegions" as a child of the placeholder concept
"ByRegionPlaceholder" using a "dimension-domain" arcrole. The
attribute "targetRole" should be set to
"http://www.xbrl.org/2003/role/link". This points to the dimension
"Regions" which will be used by the by region dimension. The targetRole
attribute points to the extended link which contains the list of domain
members, in this case the default XBRL extended link.
4. We will now repeat this same process to set up the "Products" dimension
within the hypercube. Add the placeholder concept
"ByProductPlaceholder" as a child of the "CompanyHypercube" using a
"hypercube-dimension" arcrole, setting the "xbrldt:summable"
attribute to "True".
5. Add the concept "AllProducts" as a child of the placeholder
"ByProductPlaceholder" using a "dimension-domain" arcrole, setting the
"targetRole" to "http://www.xbrl.org/2003/role/link" which contains the
list of domain members for that domain.
Next we assign the hypercube to the primary items (in this case single concept),
we perform the following steps:
1. Add the concept "Sales" to the extended link "Primary Concepts".
2. Add the concept "CompanyHypercube" as a child of the "Sales" concept
using an "xbrldt:all" arcrole. The "xbrldt:contextElement" attribute
should be set to "Scenario" indicating that these concepts will have the
dimension information within the scenario portion of a context (as opposed
to segment). The "xbrldt:summable" attribute should be set to "true" as
this will be summable. The "xbrldt:targetRole" attribute should have a
value of "http://www.SampleCompany.com/Hypercube".
Basically what you are doing here is specifying a set of concepts which can use
the hypercube.
It might seem as though it would be better to add the concepts to the hypercube
(rater that the hypercube to the concepts as we have done) but this would limit
the use of the hypercube. Any number of concepts can use a hypercube. The
XBRL processor needs to be able to resolve the tree and figure out which can be
used. Any tree can be built using abstract or concrete concepts to organize the
tree if desired. Hypercubes apply to any ancestor concept along the has-
hypercube axis.
The following is a summary of what you have achieved with all these operations:
• An XBRL processor can now perform calculations across contexts in order
to check relationships between fact values in an instance document along
the dimensions expressed in the hypercube.
• An XBRL processor can check to be sure you have placed the proper
dimension members within the contexts used on the fact values in the
instance document.



The following is a screenshot which shows what your company taxonomy should
look like after the steps above have been completed:

Note that you can see what is contained in each of the different taxonomies by
looking at the Prefix (on the left lower area of the screen shot above or on each
concept in the relations view).
Also, although the components of the dimensional information is segregated into
different extended links, by looking at the "targetRole" attribute of the arcroles,
the flow if information is the same as if it were expressed in a single extended
link.
So there you have it, a dimensional taxonomy which expresses dimensional
information for your data. Next, we will create an instance document and
actually use this information.

14.3.3.4. Understanding All, Not All
At this point it is worth taking time to better explain the has-hypercube relations
composers.
The "xbrldt:all" (one form of the three possible has-hypercube relations) arcrole
defined between the primary item "Sales" and the hypercube could actually be
one of three different options, or composers. This is worth looking at a bit more
closely. The three possible options, depending on the functionality which is
needed of the hypercube are:
• All – If xbrldt:all were used, that indicates that ALL of the dimensions
specified in the hypercube must be present. For example, in the case
above BOTH the "Products" and the "Regions" dimensions must exist in
the <scenario> portion of a context used in an instance document. Also,
they must appear in the order defined in the hypercube.



• Not All - If xbrldt:notAll were used, that indicates the opposite of ALL of
the dimensions specified in the hypercube must be present. It is the
negated version of all.
The all and notAll composers provide control over dimensions uses within an
instance document.

14.3.4. Steps to Use the Dimensions within an Instance
Document
Now we will use the dimensional information we have created above within an
instance document. In summary, we will do the following:
• Create a new instance document (Sales-Instance.xml).
• Connect the XBRL Dimensional schema for instance documents to the
instance document so it can be used.
• Connect the "Company.xsd" taxonomy to the instance document, which
will in turn connect the "Regions.xsd" and "Products.xsd" taxonomies.
This is our DTS (Discoverable Taxonomy Set).
• Add the required units information.
• Add the required contexts, including assigning the dimensional
information, based on the XBRL Dimensions specification, to the
<scenario> portion of each context.
• Enter the fact values into the instance document.
• Validate the instance document and check for calculation inconsistencies
based on the dimensional information.

14.3.4.1. Create an Instance Document
Use the following steps to create a new instance document:
1. Create new instance document.
2. Attach the schema "xbrldi-2005.xsd" so that the instance document will be
XBRL Dimensions specification aware.
3. Attach the "Company.xsd" DTS/taxonomy starting point which contains
dimensional information and concepts expressed as fact values within the
instance.
This step only gets things started. This is instance document information needed:
Name Value
Filename: Sales-Instance.xml

14.3.4.2. Add Units
Next, we add the required units; we will use Euros for this example:
Name Value
Units ID: U-Monetary
Measure iso4217:EUR



14.3.4.3. Add Contexts
Next, we need to add all the contextual information to the instance document.
Most of this is done in the normal way of assigning contexts. XBRL Dimensions
adds one additional step.
Dimensions can be added to either the <segment> portion of a context or to the
<scenario> portion. Both work in the same way.
What you don’t want to do is have some dimensional information on one element,
and other dimensional information of the same type on the other. The taxonomy
specifies which element should contain dimensional information. In our
taxonomy we stated that dimensional information must be included in the
<scenario> element.
So, how does this work?
The XBRL specification states that basically any form of XML can be used in the
<segment> or <scenario> elements EXCEPT for elements defined in the XBRL
specification. Yet we expressed the dimensional information using an XBRL
taxonomy. How can this be?
Well, the XBRL Dimensions specification plays a clever "trick" on XBRL. It
actually does not USE XBRL elements within the <segment> or <scenario>
elements, it POINTS to elements.
The XBRL Dimensions instance schema defines the "explicitMember" element
which is used in either <scenario> or <segment> to contain dimensional
information. The XBRL Dimensions instance schema does not reference the XBRL
2.1 instance schema, therefore it is NOT an XBRL taxonomy, it is simply an XML
Schema.
Within an XBRL <segment> or <scenario> element, the contents would look like
this:
<scenario>
xlink:href="Company.xsd#ID_Concept">regions:AllRegions</xbrldi:explicitMember>
xlink:href="Company.xsd#ID_Concept">products:AllProducts</xbrldi:explicitMember>
<scenario>

This is what is going on. The example above shows one scenario element from a
context with two dimension members. Any number of dimension members could
be shown, but all would basically take the same format. Lets focus our discussion
on the first.
The expression of the dimension information has several components:
• First, the element <xbrldi:explicitMember> is used to contain all of the
dimension information. This is a non-XBRL element, as required by the
XBRL specification.
• Second, the element <xbrldi:explicitMember> has two required attributes:
o The xlink:type attribute which states that this element is going to
be expressing a link and that link will be a simple link. This is very
similar to a hyperlink used in HTML which most people are fairly
familiar with using, but may not be familiar how to actually
express.
o Next is the link information itself expressed in the xlink:href
attribute. This attribute points to a specific XBRL taxonomy, in the
case above the taxonomy Company.xsd and a specific XML ID within



that document, in the case above ID_Concept. The "#" symbol is
just the syntax of doing this: documentName#ID.
• Finally, the element has a value. The value is the QName of the element
within the XBRL taxonomy which is the domain member of the dimension
of the context.
So, two things are important to keep in the back of your mind. First, the vast
majority of what is going on here will be hidden behind a graphical user interface;
what is being explained is how it works for those who happen to be interested in
such information.
Secondly, this "clever trick" has some pros and cons associated with it. The pros
are that the XBRL Dimensions is leveraging a great deal from XBRL taxonomies
such as labels, references, etc. This is a very positive thing. If these features
were not leveraged, the XBRL Dimensions specification would have to itself
express them.
However, because the XBRL Dimensions specification is leveraging XBRL
taxonomies, and because the XBRL Dimensions specification could not modify
XBRL 2.1, it has to live with certain characteristics. These characteristics are in
the category of "nuisance". All this will likely be tidied up then it is possible to
modify the XBRL 2.1 specification. Currently, XBRL International is keeping XBRL
2.1 stable, not allowing modifications.
So now that we have explained why you are doing certain things which may
appear a bit funky; we will now do those funky things.
The vast majority of the contextual information is the standard XBRL context
information. The only thing that is added for the dimensions functionality is the
content of the <scenario> element.
Below is the context information for our case study, the values of the different
portions of the contexts in the instance document. Note that all of the contexts
are shown and that the scenario element’s contents are shown in its actual XML
form. This is to provide a sense for that is going on:
Entity Date Date Scenario Element Contents
Context ID ID Entity Scheme Start End
xlink:href="Company.xsd#company_ByRegionPlaceholder">
http://www.SampleCompany 2003- 2003- regions:AllRegions</xbrldi:explicitMember>
D-2003-All SAMP
.com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
xlink:href="Company.xsd#company_ByProductPlaceholder">
products:AllProducts</xbrldi:explicitMember>
D-2002-All SAMP
D-2001-All SAMP
D-2003- http://www.SampleCompany 2003- 2003- regions:AllRegions</xbrldi:explicitMember>
SAMP
Pharm .com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
products:PharmaceuticalsSegment</xbrldi:explicitMember>
SAMP



SAMP
SAMP
Gen .com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
products:GenericsSegment</xbrldi:explicitMember>
SAMP
SAMP
SAMP
ConHealth .com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
products:ConsumerHealthSegment</xbrldi:explicitMember>
SAMP
SAMP
SAMP
OtherSeg .com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
products:OtherSegments</xbrldi:explicitMember>
SAMP
xlink:href="Company.xsd#company_ByProductPlaceholder"
>products:OtherSegments</xbrldi:explicitMember>
SAMP
products:OtherSegments</xbrldi:explicitMember>
http://www.SampleCompany 2003- 2003- regions:USAndCanadaRegion</xbrldi:explicitMember>
D-2003-US SAMP
D-2002-US SAMP
D-2001-US SAMP



D-2003- http://www.SampleCompany 2003- 2003- regions:EuropeRegion</xbrldi:explicitMember>
SAMP
Europe .com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
SAMP
SAMP
D-2003- http://www.SampleCompany 2003- 2003- regions:AsiaRegion</xbrldi:explicitMember>
SAMP
Asia .com 01-01 12-31 <xbrldi:explicitMember xlink:type="simple"
SAMP
SAMP
D-2003-
http://www.SampleCompany 2003- 2003- regions:OtherRegions</xbrldi:explicitMember>
OtherRegi SAMP
ons
D-2002-
OtherRegi SAMP
ons
D-2001-
OtherRegi SAMP
ons

As you can see there are a lot of contexts. Basically, there is one context for
each "cell" of data. This excludes the totals which are presented a number of
times, but the data of the total only appears once in the instance document.
Again, keep in mind that what is being shown is something which the computer
will see, but the interface for users will make this far, far easier to work with.
The details are being shown so that those who want to, can see what is going on.
Here are a few considerations when entering dimension information into contexts.
The dimensions should be put into the <segment> or <scenario> element
consistently or XBRL processors will report errors in your instance document. For
example, in the contexts above region information is first, followed by product
information. This is done consistently for all dimensions expressed. Also, only
one member from each domain should be put into the context; for example don't
put two "Regions" and no "Products" dimension or only one "Region" and no
"Product" dimension.



14.3.4.4. Add Fact Values
This is all the fact value information which should be used in the instance
document:
Element Name Context Ref Unit Ref Decimals Value
ci:Sales D-2003-All U-Monetary INF 32038000
ci:Sales D-2003-Pharm U-Monetary INF 20181000
ci:Sales D-2003-Gen U-Monetary INF 2433000
ci:Sales D-2003-ConHealth U-Monetary INF 6675000
ci:Sales D-2003-OtherSeg U-Monetary INF 2749000
ci:Sales D-2003-US U-Monetary INF 10214000
ci:Sales D-2003-Europe U-Monetary INF 11901000
ci:Sales D-2003-Asia U-Monetary INF 5639000
ci:Sales D-2003-OtherRegions U-Monetary INF 4284000
So, note that the fact values use the contexts and units information provided in
the other sections.
Looking at this data as it might be seen in a user interface with no presentation
(just a list), it might look like this:



14.3.4.5. Validate
The next step in the process is to validate the instance document syntax and
check for calculation inconsistencies. The following is an example of a fragment
of a validation report:



We show the actual data here again for your convenience. Note how what is on
line 4 in the validation report ties to what is presented in the data for 2001 by
product breakdown, and line 10 ties to the by region breakdown. This is repeated
for line 18 and 25 which shows 2002:
Label/Name 2003 2002 2001

Sales 32038000 35805000 32465000

Breakdown by Segment
Pharmaceuticals Segment 20181000 18150000 15275000
Generics Segment 2433000 1973000 1823000
Consumer Health Segment 6675000 6514000 5752000
Other Segments 2749000 9168000 9615000
Total 32038000 35805000 32465000

Breakdown by Region
US and Canada 10214000 12649000 10137000
Europe 11901000 10374000 10396000
Asia 5639000 4371000 3210000
Other Regions 4284000 8411000 8722000
Total 32038000 35805000 32465000

So, one concept, yet there are calculations. Also, as you can see each cell is in a
different context, yet you can perform cross-contexts calculations, which are not
allowed in calculations that use the summation-item arcrole initially released in
XBRL 2.1. Yet, the aggregator-contributor arcrole does allow cross context
calculations. Thus, the value of the XBRL Dimensions specification can be seen.



14.3.4.6. Summary
In this example we have shown how to build a set of explicit dimensions to
express the relationship between domain members. We have also created an
instance document which makes use of the dimensional information and validated
the instance document using the dimensional information.
This functionality certainly exists in many software products, but each of those
software products implements the expression of multidimensional information in a
manner proprietary to that specific piece of software. XBRL expresses
multidimensional information in the form of a global standard. Further, many
software products do not have the robust features of the XBRL Dimensions
specification.
Any XBRL processor which supports XBRL Dimensions will be able to process the
taxonomies and instance documents which express this information, thus making
this information usable across applications.
This case study shows only a very simple use case for XBRL Dimensions. Its
purpose was to communicate the basic concepts about how XBRL Dimensions
work. Additional use cases which show additional features of XBRL Dimensions is
shown in the next section.

14.4. Additional Dimensional Use Cases
We provided a detailed explanation of building a simple dimensional taxonomy
above. Next, we will provide information for several other use cases. We will not
walk through building each. See the sample files provided which have all the
taxonomy and instance files for each of these additional dimensional use cases.

14.4.1. Sector Breakdown
One common use case to financial reporting is the sector breakdown of summary
balance sheet, income statement, cash flows and other information. In the set of
files, see the subdirectory "UseCase-03-Sectors". The following screen shot
shows the presentation of such information, commonly contained in the notes to
a financial statement:



The above is a sector breakdown by business segment. Additionally, the business
segments are broken down into continuing operations and discontinuing
operations. You also have to consider the "Corporate" column, which are
basically consolidation eliminations.
Note that in this example, there is only one discontinued sector, the agribusiness
sector. While in the presentation view of this information there is only one
column of information; there are actually two sets of information in the instance
document, both with the same values basically. Both the agribusiness sector and
the total discontinued sectors need to be in the instance document for the
calculations to work correctly.

14.4.2. Discontinuing, Continuing Operations
This example shows how continuing, discontinued, and total operations are
broken out in an income statement. This use case is in the set of files, see the
subdirectory "UseCase-04-DiscontinuedOperations":

The above show an income statement for two years. Each year's income
statement is broken down into the continuing, discontinued, and the total which is
the sum of continuing and discontinued. Each line item on the income statement,
in this case, is broken down into these three categories.



14.4.3. Excluding Specific Dimensions
Sometimes, certain combinations of dimensions or "cell intersections" are not
allowed. This use case is such an example. Dimensions can be used to explicitly
exclude these combinations:

In the above table, note that reversals cannot be shown for two line items. This
can be achieve by excluding these two combinations in the dimensions definition.
Just as the presentation information above forbids these values by showing the
cells in red, an XBRL dimensions hypercube can exclude certain line items from
showing within an analysis.
The following example is provided in the sample files which takes the simple
"Sales" example we worked with earlier and makes it so "Other Segments" may
not be reported. See the following screenshot:



In the sample files, two instance documents are provided; one is valid and the
other is invalid against the constraint of not reporting the "Other Segments"
dimension.
The sample taxonomy shows, in the definition linkbase, a new hypercube which is
created to exclude this dimension from being reported.

14.4.4. Implicit or Typed Dimensions
All the examples thus far have shown explicit dimensions, meaning the domain-
members are explicitly defined. There are occasions where the number of
domain members is known, but so large that it would be impractical to list all
domain members. For example,
• Each ZIP code in the US.
• Longitudes, which span from 180 to -180.
The XBRL Dimensions specification provides a mechanism to express these types
of dimensions. The XBRL Dimensions specification calls implicit dimensions
"typed" dimensions.
For example, consider the following sample provided:

Sales are provided by customer, and we really don’t want to have to create a
domain member for every new customer we create. As such, we use an implicit
or typed dimension. See the samples provided for more information.

14.5. Dimensions Impact on IFRS-GP Taxonomy
The IFRS-GP taxonomy was created prior to the creation of the XBRL Dimensions
Specification. As such, the current version of that taxonomy (2005-05-15) does
not make use of dimensions within the taxonomy. It is highly likely that future
versions of the IFRS-GP taxonomy will make use of dimensions.
This does not mean that dimensions cannot be used with the IFRS-GP today.
Anyone desiring to use dimensions can simply create the dimensions information
as an extension of the IFRS-GP taxonomy.
However, it does mean that certain things which were constructed in one manner
in the taxonomy would have been constructed differently had XBRL Dimensions
been available at the time the taxonomy was created.
The following is a summary of several areas of the taxonomy which will likely be
reconstructed taking dimensions into consideration.



• It is highly likely that the segment information disclosures will be redone
taking dimensions into consideration. This is one clear opportunity to
leverage XBRL dimensions. For example, in the following consider line ID
number 3979. As the "Primary Segment" can be explicitly expressed and
as the relationship between the segments can be expressed using
dimensions, this would be an appropriate adjustment to the IFRS-GP
taxonomy.

• And as the concept "Primary Segment", "Geographic Segment
Breakdown", "Business Segment Breakdown" are clearly defined IFRS
concepts (domains), these can be defined by the IFRS taxonomy
framework. However, the actual breakdowns (the domain-members) are
unique to each organization reporting using IFRS; and these, therefore,
would be created by reporting entities and wired to the domains in
company extension taxonomies.
• Certain class breakdowns could use dimensions, rather than explicitly
creating concepts in the IFRS-GP taxonomy, particularly if there is a low-
level of agreement of what the proper class breakdown should be.
• Basically, any place where these is a breakdown using items or tuples can
be reconsidered and perhaps dimensions may be more appropriate. It
many cases what exists is appropriate, but in other cases this new options
may prove superior.
There are a few other areas where the IFRS-GP taxonomy framework could
enhance comparability by creating clearly defined concepts/components which
can be used for cross company comparisons.
For example, creating the dimensions "Actual", "Budgeted" and "Variance" may,
or may not, be appropriate. But where it is appropriate, this type of
comparability enhancement would be quite useful by having the base taxonomy
actually define this information.

14.6. Dimensions and Tuples: Opportunities and Issues
There is a bit of a potential conflict between dimensions and tuples because they
can both be used to perform similar tasks in some cases. In fact, one could ask
the question, "Should XBRL get rid of tuples?" XBRL certainly should not get rid
of tuples, however, it is the case that:



• At times it is clear when dimensions should be used, at times it is clear
when tuples should be used, and at times you are in a "gray" area where it
is less clear whether the use of tuples or dimensions is the most
appropriate.
• Sometimes this decision can boil down a desire to make writing
applications which work with XBRL easier to create; not having to deal
with tuples (basically making everything in instance documents and
taxonomies items and contexts/dimensions). This is a very appropriate
choice, one which was used for the COREP taxonomy.
A typical Excel user would have an easier time making use of XBRL if tuples did
not exist. It may be appropriate that an XBRL specification be created, similar to
the FRTA which constrains XBRL for financial reporting purposes, which excludes
the use of tuples. Somewhat of an XBRL Forms type specification. While users of
XBRL are free to do this now, this type of specification might make it easier to
exchange XBRL based information.
Several things should be kept in the back of your mind when deciding when to
use tuples and when to use dimensions:
• When tuples are being used, because all concepts in XBRL are global, it is
the case that it is impossible to constrain the number of occurrences of a
specific tuple. For example, if you wish to collect data for, say, types of
related parties; using tuples you cannot express that you want one tuple
only for all related party transactions with the parent, one tuple only for
subsidiaries, one tuple only which summarizes information with key
employees, etc. Basically, you cannot constrain the number of times a
tuple appears in an instance document.
• When tuples are used, sometimes it is more difficult to express the
calculations you desire to express.
• Dimensions provide a nice way of "enumerating" the values which can
appear, and the enumerations are extensible. This cannot be done
effectively using tuples and there really is no standard, agreed upon way
to achieve this using tuples.
• Dimensions do not appear in a taxonomy in a way where it makes it
apparent what data a taxonomy desires to collect. For example, you don’t
"see" the dimensions in the taxonomy in a manner where you know that a
specific concept requires that, say, 5 specific dimensions of that concept
are to be reported in an instance document.
• Dimensional calculations have the same issues as normal XBRL
calculations. The "no imputed values" (no value creation by an XBRL
processor) still applies with dimensions; XBRL processors are not allowed
to impute values.
• There are issues relating to using concepts both with the expression of
dimensional information and also not expressing dimensional information.
For example, say "Assets, Total" is used on the balance sheet. There are,
say, 20 other items on the balance sheet which add up to "Assets, Total",
so the concept "Assets, Total" and the other 20 concepts adding up to
assets need to be in the same context. However, "Assets, Total" is also
used in the sectorial breakdown, disclosing assets by geographic segment
or business segment, and these are expressed using dimensional
information within contexts. Basically, where fact values/concepts
reported which use dimensional information must interact with fact



values/concepts which do NOT use dimensional information, conflicts can
arise.
There are other decisions which need to be made when using dimensions. The
following will give you an idea of these issues:
• Consider the concept "Property, Plant and Equipment, Net" in the IFRS-GP
taxonomy.
• Classes of "Property, Plant and Equipment, Net" could be expressed in a
taxonomy in a number of different ways, each approach having a distinct
set of pros and cons:
o Items can be used to express information for each class, but this
results in a rather large taxonomy. Also, if you don’t desire to use
that set of classes, all those items really should be prohibited.
o Tuples can be used to express this information, basically wrapping
each class within a tuple. But with this approach, nothing prevents
the class, say, "Land" from being in an instance document twice.
o Dimensions can be used to express the class information for
"Property, Plant and Equipment, Net"; however, if you look at a
taxonomy which uses this approach, it is not apparent that you
must disclose information for classes of "Property, Plant and
Equipment, Net".
• If different extension taxonomies to the IFRS-GP taxonomy used different
approaches, then comparison of financial information would be more
challenging.
The point of all this is that there are sometime no definitive right or wrong
answers to many of these issues. However, it is important that agreement be
achieved or using XBRL could be more challenging than it needs to be.

14.7. Conclusion
So, as you can see XBRL dimensions adds a necessary, and a very powerful,
feature to XBRL: the ability to articulate, in a global standard way, what is
typically seen as "drill down" information for an reporting entity. Having this
information expressed as a global standard facilitates the exchange of this
information between different software applications, rather than locking users into
one software application whose information cannot be exchanged effectively with
others without human intervention.
The more the dimensional taxonomies are shared by reporting entities, the better
the comparability between reporting entities. Therefore, it makes sense for some
taxonomy frameworks, such as the IFRS taxonomy framework or the US
taxonomy framework, to create some of this dimensional information which is
common to entities using those frameworks.
The XBRL Dimensions feature set is robust, covering common use cases of
financial reporting. There may be some obscure use cases which have not been
discovered by this specification.
Some taxonomies created prior to the existence of the XBRL Dimensions
specification will need to be adjusted to take its functionality into consideration.
However, that does not mean that those taxonomies cannot be used with other
taxonomies which express information today.
The XBRL Formulas Linkbase will be XBRL Dimensions aware.


Chapter 14-understanding andusingxbrl-dimensions

More Related Content

Viewers also liked (8)

Similar to Chapter 14-understanding andusingxbrl-dimensions (20)

More from jps619 (14)

Chapter 14-understanding andusingxbrl-dimensions