1 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

2 Preamble

The main reason why the XBRL Global Ledger Working Group considers this document an important contribution to the advancement not only of XBRL GL but of XBRL as a whole is not as yet another chapter in the "tuples versus dimensions" discussion that is ongoing within the XBRL community, but rather to clear the ground from the basic misconception that the tuples vs. dimensions discussion has anything to do with XBRL GL in the first place.

The question that Eric E. Cohen, the main author, quotes in the document, "Why is it that XBRL GL has not moved to dimensions yet" is indeed one that we are asked frequently, and is a consequence of the syllogism "XBRL is moving away from tuples and towards dimensions, XBRL GL is based on tuples, therefore XBRL GL should move away from tuples and towards dimensions". I strongly feel that this syllogism implies little or no understanding of the basic nature of XBRL GL and its very reasons to exist: XBRL GL is structurally different from other XBRL taxonomies because it deals with detailed information. A more satisfactory statement would be "Architects of XBRL FR taxonomies are moving away from the use of tuples in favor of the use of dimensions" (no XBRL GL in sight), and then the discussion can start on whether this choice makes sense, and why or why not. But our primary interest in contributing this document to the community is, of course, making sure that the discussion around XBRL GL is based on facts and not assumptions.

Eric's document is an excellent and complete analysis of the reasons why XBRL GL is not based, and should not move to, dimensions, and it does so both from a theoretical point of view and by providing very practical examples to support the points made.

From my perspective, there is another important point that needs to be made. XBRL GL is actually the place where tuples and dimensions work together. The Summary Reporting Contextual Data (SRCD) ^{[ 1 ]} module of XBRL GL provides an explicit, straightforward way to link detailed data represented with XBRL GL and summarized data represented with XBRL for financial reporting (or any other XML schema, I may add), and it provides the tools to do so for both dimensional and non dimensional taxonomies. Whatever choice taxonomy architects make in building end reporting taxonomies (tuples, dimensions or a mix of the two), XBRL GL is able to provide a standardized way to link the underlying detailed data to those end reporting taxonomies.

This has extensive implications for the value proposition of the joint use of XBRL GL and XBRL taxonomies for financial reporting: among others, it allows to work with hybrid forms of end reporting where both hierarchical (tuple based) and dimensional data coexist. In many situations where a strictly dimensional architecture in the end reporting taxonomy does not provide enough flexibility, a solution based on hybrid reporting and on the joint use of XBRL GL and XBRL FR data is an excellent alternative to consider, and may even help move beyond the "tuples vs. dimensions in financial reporting" discussion.

Gianluca Garbellotto - Chair, XBRL GL Working Group

3 Introduction

It is the case that the design of XBRL's Global Ledger Framework (XBRL GL) uses "tuples" extensively. It expresses highly hierarchical information and is modeled using the XML Schema document content model.

It is likewise the case that the XBRL US UGT (US GAAP Taxonomy) team has chosen to use Dimensional Taxonomies to the exclusion of tuples. ^{[ 2 ]} COREP has taken a similar approach Some of XBRL's most notable participants are very vocal about the weaknesses of tuples.

Taxonomy efforts, such as the Netherlands Taxonomy Project ^{[ 3 ]} , find themselves under increasing pressure to move from any usage of tuples to the use of dimensions instead.

For this, and other reasons, the XII Board of Directors recently put out a reaffirmation ^{[ 4 ]} of the stability of the XBRL 2.1 Specification. In it, they state:

"What is clear from this experience is that almost all facets of the original specification have applicability and that virtually none are redundant. It is our belief that changes to the specification at this time would be unnecessarily disruptive to adoption and implementation of XBRL around the world, especially in light of the limited potential gains."

Nonetheless, some of the XBRL community continues to ask, "Why doesn't XBRL GL use dimensions - and stop using tuples?"

The purpose of this document is to be an apologetic. The author is serving as an apologist (or an "apologete"). Both in the meaning and conceptual underlying information and design, and in the use of XBRL as a technology, the author believes that the dimensions abstractly are the wrong way to express the bulk of the information XBRL GL was meant to represent, and the Dimensional Specification, as written, is an inappropriate tool to replace tuples for XBRL GL to leverage with its present modeling and scope.

At the same time, the apologete wishes to express support for the purpose of the Dimensional Specification and to encourage its usage where appropriate, which is a wide range of areas of expression. With some modification to the Specification, the author believes that it could become an important tool in improving the communication of ties between detail and summary and even providing validation to code sets that could be used within XBRL GL.

4 Background

Tuples is the use of XML Schema document content model to express complex (hierarchical) information. Prior to the XBRL 2.1 Specification, tuple relationships were captured using presentation and definition links; with 2.1, the relationships were captured using complexType structures.

Dimensions uses XBRL taxonomies to provide content for, and validate, the segment and scenario of XBRL instances.

Opponents of tuples cite the following issues, amongst others:

• Difficulty of extensibility, as the XML Schema-provided extensibility tools, such as redefine, have not proven themselves, and the XBRL-provided tools, such as the similar-tuple definition link role, has not found its way into common use.
• Mixing of metadata with data, as tuples are sometimes used as a short-cut for extending taxonomies. Metadata winds up expressed in the instances instead of being put into the taxonomies.
• Tuples provides a second way of doing what dimensions can also represent, bringing confusion into the market; that dimensions can do anything tuples can plus a lot more.
• Dimensions overlap of tuples is compounded by the need to have better dimensional tooling in the marketplace, and by using dimensions for all such purposes it encourages the development of more excellent dimension-capable tools; some critics would say that tuple-capable tools are still in their infancy.
• XBRL development efforts, such as formulas and versioning, focus more on context/segment-oriented development and cannot focus on tuple-oriented information. Versioning can not include all of the aspects of XML/XML Schema versioning differences; formulas cannot be used to create new tuple-oriented instances from old ones. A move from tuples to dimensions will let XBRL GL take more advantage of XBRL's development efforts.

Opponents of the indiscriminant use of dimensions cite that dimensions:

• Equally and oppositely force the movement of data into metadata. Data (the key or index fields in record oriented information) must be placed into taxonomies to be used.
• Force content into context. As Dimensions populates segment and scenario of instances, the key or index fields of record oriented information must be stored in the segment (or scenario).

5 Why Consider a Dimension Only Approach For XBRL GL Or Any Other Taxonomy

1. XBRL US has chosen to use Dimensions to the exclusion of tuples in the development of the XBRL US GAAP taxonomy.
2. Dimensions provide a way to make complex information extensible using XBRL taxonomies rather than relying on XML Schema's extensibility tools, which have not been agreed upon consistently in the XBRL community.
3. Some XML notables note that if everyone moves from tuples to Dimensions, then XBRL design will be simpler, and software developers will have less to worry about.
4. Dimensions could solve some XBRL extensibility issues, particularly related to enumerations. XBRL GL has its GLTFTA ^{[ 5 ]} (Global Ledger Taxonomy Framework Technical Architecture) document which lays out how XBRL GL's schema files are fragmented to allow the modification and enumerations and addition of new modules, which requires rewiring the entire taxonomy's interrelationships.
5. Dimensions are "hot", strongly supported by a number of taxonomy development efforts, and gaining better tools support than tuples.

6 Why Not Consider It

1. Dimensions was not designed to represent highly hierarchical data. Dimensions populates and validates segment/scenario - information that has already been summarized.
2. XBRL GL doesn't use segment/scenario; the underlying information represented by XBRL GL is largely pre-summarization, and XBRL provides many dates where contexts provide one, many and predefined scenarios where context provides a blank slate, and many explicit pieces of detail (e.g., customer information, location information, product information) where segment provides, once again, a blank slate that can be formalized in a dimensional taxonomy.
3. Accounting system data modeling is pre-summarization. Dimensional system, such as data warehouses, trade-off losing information (storing vastly decreased amounts of detail) for the sake of smaller data sets in data warehousing and use dimensions for quicker explicit queries. XBRL GL is largely pre-summarization.
4. The need for Dimensional support in products is vital - but pushing tuples out the door to gain that support is a trade-off we don't accept.
5. No user has said they would use XBRL GL if only it used a dimension approach instead of a tuple approach.
6. Prospective users have said that they are pleased to see a normal hierarchy in XBRL GL, as it is more familiar and ties to their record-oriented information better, in contrast to "flat" XBRL as traditionally seen in financial reporting.

Some other discussion, discussing

• Dimensions as meaning/conceptual
• Dimensions as technology

First of all, it is important to state that dimensional approaches are valuable as a point between the underlying detail and the end reporting. For example, a company may have two dozen product categories noted at the transaction level; they may report four major categories on their financial statements. An intermediary Dimensional taxonomy that relates the detail level to the reporting level and then provides the linkage from underlying detail (with the product categories) to the end reporting (using the major categories) is very valuable. The organization may not, and probably will not, want to disclose that reconciling Dimensional taxonomy to the public; they do not have to disclose those details now; it would be for internal use only.

The use of Dimensions is a pre-consideration of ways that data will be sorted or summarized. XBRL GL does not start of with any such limits. An entry in the Chart of Accounts can have an unlimited number of subaccounts or segments, for example. Under different circumstances, any of these could be part of a summarization process. In the tuples approach, the unlimited number of segments is captured in the instance; in the Dimensions approach, they would all have to be captured in Dimensional taxonomies and contexts created for their various permutations.

Extending this out conceptually, a company may wish to slice and dice by almost any piece of data in a transaction - by customer or customer type, by product or product category, by type of work performed, by any reporting segment or job … the list goes on. In a dimensional approach, all of these types of facts would be pulled from the data/content and placed into the context/segment/dimension - in the wild extreme, there is a single number in the content and dozens of explanatory fields in the context's segment, leading to a different context for every amount - and, due to the nature of XBRL GL, the impossible need to associate MULTIPLE contexts to an amount. (As ludicrous as this sounds, if an invoice, with its primary invoice amount, lists multiple line items, with products and their product categories provided, some way of expressing these multiple lines of information is necessary - the focus may need to shift to a one-to-one at a document number/type basis, which goes against the generic structure of XBRL GL.)

Considerations in staying with tuples or moving (entirely) to Dimensions

1. Changing the design of XBRL GL from tuples to a Dimensions-only approach would require a complete remodeling of XBRL GL without obvious compensatory benefit.

   As it states at the XBRL web site, "The Dimensions 1.0 Specification is a modular, optional extension to the XBRL 2.1 Specification which allows XBRL taxonomy authors to define and restrict dimensional information for instance authors to use in the segment and scenario elements of the context element of XBRL instance documents."

   Dimensions is entirely focused on segment and scenario of the contexts of instances. XBRL GL doesn't use the segment and scenario of the contexts.

   XBRL GL has not focused on the contexts in instances for a number of reasons:

   • The segment of the context is drawn from distinct pieces of information explicitly expressed in XBRL GL: reporting segments, customer information, inventory information, sales information.
   • The period information of the context is not robust enough to capture the many different dates that might be associated with handling transactions and other XBRL GL information.
   • The scenario of the context is also represented explicitly elsewhere in XBRL GL.

   Therefore, Dimensional information would have been - and could still be, with modification to the Specification - useful as a means of storing and validating account and classification-oriented information, formal code-lists; but it was designed only for segment and scenario.

   There are systems in place already using XBRL GL - completely changing its design would place an enormous burden on those already leveraging XBRL GL.

2. SRCD provides the link from XBRL GL's detail to XBRL FR's summarized information expressed in Dimensions.

   Although it was our original hope that Dimensions would provide a link from the detail of XBRL GL to the aggregation of end reporting, the necessary limitation to segment/scenario limited its usefulness. The SRCD ^{[ 6 ]} (Summary Reporting Contextual Data) module was developed to be able to provide an explicit link from the detail of XBRL GL to the summarization of FR, including dimensional support.

3. Analysts of accounting and ERP data believe that Dimensions, common to data warehousing, represent a trade off.

   Data warehousing relies on dimensions to simplify queries and reduce the amount of data stored to support the queries. Dimensional approaches pick up at a certain point where loss of information is a trade off for those queries. XBRL GL is about being able to represent the full detail, and dimensional approaches are inappropriate for that kind of representation.

4. Representing highly nested data with Dimensions pushes tremendous amounts of data from "data" into contexts.

   In a dimensional/segment approach, the "key" for each record, as represented by Dimensions, is placed in the segment or the scenario, and each associated fact is associated with that segment by the reference to the context. As XBRL GL represents data with multiple records within multiple records, the segment would become as complex as the number of layers deep a record is.

5. Record oriented information is not consistent with Dimensions when the key repeats in the same time period.

   Record-oriented information is sometime repetitive - the "key" fields (the necessary content in the segment so that the related facts can be kept together through referencing the same context) must be complex to be unique (customer number may not be sufficient; customer number/date may not be sufficient; customer number/data/document number may be where it gets unique) - this can get very ugly.

   In a common example, two invoices are sent to the same client representing two simultaneous shipments. The key relationship, the client, would be common across the detailed information in those two invoices. However, either two contexts that are exactly the same must be created (which violates the rules of XBRL), or some other difference must be found - such as the document number being placed in the segment as the key difference.

   This compounds as each invoice has multiple line items, and those line items must also allow duplicates of item numbers, so a line number must become part of the key placed in the segment. Pretty soon, all of the data will be found in the segment except the primary amount. Essentially all of the data will be placed in contexts, and there will be a separate context for every line on an invoice or any other type of detail.

6. Flattened data can be very verbose data.

   By flattening out the data, "parent information" and all ancestor information must be duplicated, leading to verbose documents. See the "before and after" illustration at the end of this document.

7. Dimensions puts data into contexts; less familiar to non-XBRL developers.

   A meaningful argument against the indiscriminate use of tuples is that, by using them, we are putting repetitive metadata, better stored in taxonomies, in instances, with the accompanying loss of consistency, validation, and analysis. However, indiscriminate use of dimensions likewise blurs the difference between taxonomies and instances, putting data into taxonomies and forces data to become metadata.

   Dimensions likewise blurs the distinction between content and the context related to that content. We understand that the terminology of XBRL can be confusing (for example, despite the similarity in names, human readable definitions are not found in the definition linkbase; they are found in the label linkbase; likewise, financial reporting segments are not synonymous with the segment of the context, and don't get me started on the lax and formal meanings of general ledger, journal and even account). However, the context has always been understood as contextual metadata to provide the meaning for business facts (the content); a dimensional approach means having to take the key/index of every record and move it from the content area to the context/segment. This is unintuitive and confusing. A data modeler less familiar with XBRL will not understand why so many data fields will be placed in the segment in a flat structure rather than placed hierarchically with the associated data.

7 Before And After

Without major remodeling, it is not a simple task to turn XBRL GL into dimensions-only. Determining what remains content and what becomes dimensions is not easy.

Illustrated hereafter is a simple, record-oriented data structure represented in XBRL GL - a definition of reporting periods for a company. In XBRL GL today, this is a few layers deep:

Accounting Entries

• (Entity Information) - only a categorizer
  • Reporting Calendar Information
    • Reporting Period Information

In a dimensional approach, key fields related to the batch of accounting information (the [accountingEntries] level), to the individual reporting calendar ([the [reportingCalendarCode] level, assuming the code is unique) and the reporting period level (the [periodIdentifier] level, assuming that identifier is unique) must be placed in the segment of contexts. The hierarchical data is flattened out. This looks like it creates many non-reusable contexts, and requires the duplication of header information (somewhat similar to the effect when you bring a very hierarchical XML file into Excel) with little increase in comprehension or other obvious benefits.

In a more hierarchical data representation, such as an invoice, the duplication of key information that is not necessary in a hierarchical design becomes even more apparent. In an invoice, the hierarchy can gets significantly deeper. If the purchaser provides an office and a cell phone number on a particular order, that hierarchy gets deep under the current modelling:

[accountEntries] -> [entryHeader] -> [entryDetail] -> [identifierReference] -> [IdentifierContactInformationStructure] -> [identifierContactPhone]

Let's look at the simple representation of reporting calendars.

A company wishes to represent two reporting calendars, their Standard Calendar for 2003 (SC2003) and their Standard Calendar for 2004 (SC2004). They report on a 4-5-4 basis rather than calendar months, and wish to describe explicitly what those dates are. (In the simplified data, it is calendar months). They have a 13th period for year-end close. So they have two calendars, each with 13 periods for a total of 26 periods.

In today's XBRL GL, that is one context (not really used for anything); in a dimensional XBRL GL, that is a minimum of 26 contexts to capture the calendar/period key information.

BEFORE

190 lines of code representing two years of reporting calendars.

AFTER

329 lines of code to represent the contexts and only the first two of 24 periods presented. (Note: the segment information is not in this illustration represented using the appropriate vocabulary of dimensional entries.) That would presumably be a much more verbose representation.

For example, the current

would probably look more like

-- Instance begins here --