Table Linkbase Overview 1.0

Public Working Draft 21 December 2011

Copyright ©2011 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/WGN/table-linkbase-overview/PWD-2011-12-21/table-linkbase-overview-WGN-PWD-2011-12-21.html>
Editors:
Herm Fischer, Mark V Systems <fischer@markv.com>
Victor Morilla, Banco de España <victor.morilla@bde.es>
Contributors:
Geoff Shuetrim, Galexy Pty. <geoff@galexy.com>
Masatomo Goto, Fujitsu Ltd. <mg@jp.fujitsu.com>
Roland Hommes, RHOCON <roland@rhocon.nl>
Bartosz Ochocki, BRAG <bartosz.ochocki@br-ag.eu>
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.com>

Status

Circulation of this Public Working Draft is unrestricted. Other documents may supersede this document. Recipients are invited to submit comments to rendering-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

A table linkbase establishes a standard way to create views of the concepts defined in XBRL taxonomies that overcomes most of the limitations of the presentation linkbase. Rather than providing a simple arrangement of concepts as a hierarchy, it enables the definition of tables with multiple axes. The components of these axes are not limited to individual items; instead, they can be defined in terms of a combination of dimensions, time period references, units, entities or any other property that can be used to identify the financial facts represented by taxonomies.

Table of Contents

1 Introduction
2 Class Models
3 Use Case Examples
3.1 Fixed predefined tables
3.2 Fixed table with an open axis
3.3 Financial Reports
3.4 Global Ledger Reports

Appendices

A Intellectual property status (non-normative)
B Acknowledgements (non-normative)
C Document history (non-normative)
D Errata corrections in this document

Figures

1 XBRL Table Model Classes and their Specifications
2 Table participation in rendering semantics


1 Introduction

Presentation linkbases, according to the XBRL 2.1 specification, establish relationships between items in a taxonomy for presentation purposes. For many years, this resource has allowed taxonomy authors to arrange sets of concepts into hierarchical representations, helpful to convey better the meaning of those financial concepts as part of a group, rather than as isolated, individual elements. These relationships have served other purposes, such as the creation of user interfaces, or the rendering of instance documents. Simple balance sheets and profit & loss statements are a good example.

The release of XBRL Dimensions introduced a new degree of flexibility in the design of taxonomies. It enabled the modelling of complex data and richer relationships. However, under this specification, a financial concept could be expressed as the combination of several elements (primary item plus a variable number of pairs dimension / members) rather than as a single item. This new facility surfaced an important limitation in the capabilities of XBRL to express presentations or views of multidimensional models. This has been partially solved in different projects using different approaches.

The purpose of the table linkbase is to provide taxonomy authors with a standard way to define views of the concepts defined in XBRL taxonomies that overcomes most of the limitations of the presentation linkbase. Rather than providing a simple arrangement of concepts as a hierarchy, it enables the definition of tables with multiple axes. The components of these axes are not limited to individual items; instead, they can be defined in terms of a combination of dimensions, time period references, units, entities or any other property that can be used to identify the financial facts represented by taxonomies.

As a consequence, a table linkbase provides a better understanding of the concepts modelled in taxonomy files by combining them with other concepts as part of tables. A table represents a subset of the complete model provided by a taxonomy, and thus it could be used to represent reporting requirements (for instance, the subset of data required by a supervisor); to represent a view of the data for analytical purposes; or to present an instance document in a certain way.

Though formatting artefacts are not part of the table linkbase, tables are intended to be the foundation of the rendering specification. Tables identify the data to be rendered, its order and some basic graphical arrangement. This specification will be complemented by the rendering specification to allow the possibility of specifying accurately the way an instance document ought to be rendered and the way its content should be formatted.

This overview provides examples and explanations as an introduction to the syntax and semantics of the table linkbase. The accompanying specifications provide the feature descriptions in a rigorous manner for implementation and validation.

2 Class Models

The figures below provide a model of XBRL table classes, showing the mapping of classes to the table linkbase specifications Figure 1 and a model showing how XBRL Tables can, as an example of their use, participate in XBRL rendering semantics Figure 2.

Figure 1: XBRL Table Model Classes and their Specifications

Figure 2: Table participation in rendering semantics

3 Use Case Examples

The use cases are categorized as follows, and correspond to test variations for reference:

3.1 Fixed predefined tables

Corresponds to XBRL examples of Eurofiling forms, usually represented by spreadsheet workbooks with multiple worksheet tables, each in a fixed format.

  1. Simple table, two rows represent primary items, two columns represent members of one dimension

  2. Same but columns represent two dimensions with fixed assignment of members to columns, both columns dimension D = member d0, column 1 dimension E = member e1 and second column dimension E – member e2

  3. Similar to example 2, but three columns, first has no value for dimension E (E is not in the context, could be default or absent), may represent an aggregation for columns 2 (E = e1) and 3 (E = e2). Uses a non-abstract aspect rule member for D, which causes the row-spanned column header appearance

  4. An alternative way to represent the column for no E value, by an explicit coordinate with no E-dimension rule, instead of a non-abstract D coordinate member rule.

  5. Demonstrates coordinate inheritance and override, second column overrides dimension D inherited from first column coordinate member

  6. Introduces use of z-axis (for a third dimension, F)
  7. Z-axis has two values (causing Cartesian product with x/y axes)
  8. Introduces nested coordinate members in the z-axis.
  9. Introduces two separate z-axes (so that the Cartesian cross-product of their members represent the coordinates on the z-axis).
  10. Same as 9 but the two z-axes are merged into a single z-axis specifying each of the Cartesian cross product members as separate coordinate members.
  11. A transposed two row, two column example with primary items in columns and dimensional coordinates in rows, and dimension D is explicitly removed in the second row coordinate member.
  12. Two x-axes (of dimensions), causing the columns to represent the cross product columns of both dimensions, e.g., first pair of columns for value of D = d1 with two E-value columns, and then the second pair of columns for value of D = d2 with each E-value columns.
  13. Similar but two y-axes, first a primary item coordinate, and nested second a dimension coordinate.

3.2 Fixed table with an open axis

Corresponds to XBRL examples of Eurofiling forms where a range of rows or columns represent a variable number of entries (here distinguished by a typed dimension value).

  1. Open axis example. Rows are primary items, column is a typed dimension value (example is a simple typed dimension with a string value). A rendered table from an instance would have a dynamic number of columns, to represent the typed dimension values that have either primary item represented by a fact. If this were used as an entry form, the string value of the typed dimension would require an editable column header cell corresponding to the string value of the dimension.
  2. Two x-axes, one predefined and one open. The table shows the top five ranked country dimensions for primary items (in rows). The first coordinate (column) is predefined, having typed rank value 1, second has rank 2, etc. The second coordinate for each column is the country dimension, an open Axis using a filter for the country dimension. Causes the country having rank one to be in second column header row of column 1, country of rank two in second column header row of column 2, etc.
  3. A deposits-on-hand table in local currency and equivalent in Euros: The y axis represents a primary item that reports deposits on hand in various currencies, each of which is a dimension. The y axis specifies the primary item and a relationship axis for the currency dimension values. Each fact is reported in the local currency, to be shown in the first column, and in equivalent Euros, to be shown in the second column. The first column has the local unit (non-Euro) and the second the Euro-equivalent (in EUR units), these facts are otherwise aspect equal to each other.

3.3 Financial Reports

Corresponds to US-GAAP or IFRS filings.

The y-axis (rows) are:

  1. a selection axis representing the extended link role (schedule) for the balance sheet, and
  2. a concept relationship axis representing concept hierarchy according to a linkbase (presentation used for 2010 examples), within the schedules (extended link roles) of the presentation linkbase according to the desired schedule display.
The schedule in these examples is assumed to be inferred from the type of filing, representing fact-related DTS information (because the fact specifying form type provides this association), and the hierarchy of members in the rows represents non-fact information (from the DTS). Concept names in the balance sheet must be shown for ancestors of a reported fact regardless of whether the concepts between the root and the reported descendant have values.

  1. A balance sheet. Columns represent periods. Rows represent presentation linkbase hierarchy of concepts in the extended link role for balance sheet. In this example the extended link role is known in advance.

  2. A Risk-Return instance (partial) showing multiple relationship axes rendered.

    The y-axis provides the presentation linkbase. In the sample RR instances provided, standard link roles were used, so dynamic discovery (the case of US-GAAP filings) is not required.

    The x-axis provides two dimensions in two axes (Cartesian products of member possibilities, with non-occupied combinations elided, because only some make sense.)

  3. A report on unused contexts in instance document (This is not fact reporting in the traditional sense, however it is required by US-GAAP, IFRS, and SBR-NL)

3.4 Global Ledger Reports

Requires an open axis for the rows to identify participating tuples from the GL instance that have the required contents, based on their location. Uses selectionAxis to identify these tuples.

  1. A Global Ledger report of a trial balance (showing ending balance of XII website sample file BP_trial_balance.xml).

  2. A Global Ledger report of assets (showing book and tax depreciations of XII website sample file BP_FixedAssetList.xml).

Appendix A Intellectual property status (non-normative)

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

Appendix B Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix C Document history (non-normative)

DateAuthorDetails
01 October 2011Herm Fischer

Initial draft

11 October 2011Hugh Wallis

Incorporated comments from Victor Morilla regarding the abstraction of this specification away from the specific rendering use case

13 October 2011Herm Fischer

Revised abstract and introduction per Victor Morilla

14 October 2011Hugh Wallis

Editorial in abstract and introduction

03 November 2011Herm Fischer

Working group updates: replace prior aspectRuleAxis. Replace relationshipAxis model with subtrees of compositions and abstract relationshipAxes that have concrete instances of conceptRelationships and dimensionalRelationships. Replace axis-member notion with that of axis subtree composition.

19 December 2011Herm Fischer

Update rendering UML per F2F Tokyo 2011-12-26 with Masatomo Goto. Editorial updates suggested by Roland Hommes in WG e-mail of 2011-12-08.

Appendix D Errata corrections in this document

This appendix contains a list of the errata corrections that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Rendering Working Group up to and including 21 December 2011.

No errata have been incorporated into this document.