Differentiating XBRL Modules

In This Chapter

Getting to know the XBRL modules Using XBRL with the multidimensional model Taking advantage of XBRL Formula Maintaining your XBRL using XBRL Versioning Introducing the XBRL Global Ledger taxonomy
BRL is really a family of specifications. In this chapter, we meet that family in detail. Although this chapter doesn’t make you an expert in any of these XBRL modules, it helps you realize what the modules are and what you can use them for.
Although not technically a module, we cover the XBRL Global Ledger taxonomy in this chapter, too. We show you what it is and how it may be useful to you.

XBRL Is a Set of Specifications

XBRL isn’t just one specification; rather, it’s one base specification and several additional modules that each add specific functionality to the base XBRL specification. You can use the additional modules if you need the functionality that they provide, or you can ignore them if you don’t need the functionality. The modules are physically separate packages of functionality that you can call on when you need to.
Part of the reason these additional modules were created was that real-world use of XBRL showed that the additional functionality was needed. Rather than have each XBRL implementation create the required functionality separately within that implementation, the members of the consortium decided, in certain cases, to work together to create something that all implementations could use as deemed appropriate. The result is the additional modules that expand XBRL’s functionality.

PWDs, CRs, and RECs

In the XBRL world, a specification can achieve various levels. The first level is that of a public working draft (PWD). A public working draft is a version that is released to the public for feedback and comments. Public working drafts can change, sometimes dramatically.
The next level is that of a candidate recommendation (CR). A candidate recommendation is a document that has been widely reviewed and is published to gain implementation experience prior to being published as a recommendation. A candidate recommendation is less likely to change, but can if implementation experience shows that a change is necessary.
The final level is that of recommendation (REC). Progressing through the public working draft stage and candidate recommendation stage vets the materials, and eventually they become a recommendation. At the recommendation stage, two or more members of XBRL International have created interoperable implementations of the recommendation specification. A conformance suite, which exercises all aspects of the specification, is used to ensure software vendor interoperability.
The granddaddy of all these modules is the XBRL 2.1 specification. The modules don’t work with older versions of XBRL (2.0, 2.0a, or 1.0). Further, each module is compliant with the XBRL 2.1 specification. The modules were created using the extensibility features of XBRL 2.1. As such, the XBRL modules won’t break compliant XBRL processors.
XBRL International provides a technical working group roadmap that outlines timelines of its future plans for XBRL and for the additional modules.
The URL for the roadmap is www.xbrl.org/XSB/XBRL-International-Technical-WGs-Roadmap-2008-11-26.htm. (To avoid having to type these long links, go to www.topic.com/go/xbrl. This takes you to a landing page where you can click the link you need.)
The base XBRL 2.1 was published in December 2003 and has remained unchanged since that time. There are no known plans for changes to the base XBRL 2.1 specification communicated in XBRL’s roadmap, which goes to the end of 2010.

The XBRL Family of Specifications

The patriarch of the XBRL family of specifications is the XBRL 2.1 specification that is the base for each module. Here are the modules in the XBRL family of specification:
XBRL Dimensions Specification: Allows XBRL taxonomy authors to define and restrict dimensional information that XBRL instance authors may use in the segment and scenario elements of a context element of XBRL instances. Fundamentally, XBRL Dimensions enables XBRL taxonomies and XBRL instances to be created that leverage the multidimensional model.
XBRL Formula: Allows XBRL taxonomy authors to create business rules that you can then use to validate XBRL instances. XBRL Formula also enables users to programmatically generate XBRL instances based on a set of rules.
XBRL Rendering Specifications: Provides standard mechanisms for rendering information contained within XBRL instances so that a human can use it. Humans still want, or have, to work with information contained in XBRL instances, and this specification gives them various ways to get at the documents’ information.
XBRL Versioning: Lets you communicate changes made to XBRL taxonomies (changes to the concepts, resources, and relations contained within a taxonomy). These specifications help both taxonomy publishers (who need to communicate changes) and taxonomy users (who need to understand the changes). This versioning control helps you with the process of, say, remapping your business systems for changes to an XBRL taxonomy.
Generic Linkbase Specification: Allows for the creation of new types of resource or relations networks. The sky is literally the limit! The ability to create new types of resource and relations networks allows for expressing and connecting new types of metadata to an XBRL taxonomy in a similar manner to other XBRL linkbases.
We drill into each of these family members later in this chapter. A second cousin is XBRL Global Ledger. It’s not really a module, but it’s included on the XBRL roadmap. XBRL Global Ledger is more like an application profile, a way of making use of XBRL, which is provided by XBRL International.

Leveraging the Multidimensional Model Using XBRL Dimensions

In order to understand what XBRL Dimensions is and why it’s important, you need to be familiar with the multidimensional model. Most business people make use of the multidimensional model, but they may not realize it or understand that they are. Because this understanding is important, we take time to explain about multidimensional analysis and the multidimensional model. (See www.xbrl.org/Specification/XDT-REC-20 0 6-0 9-18.htm for a copy of the XBRL Dimensions specification.)

Using the model for analysis

Most people understand what a database is. A database is just a way of storing data used by business systems. Pretty much all databases these days are relational databases. Databases are an organization of tables that contain fields and rows of data. Figure 16-1 shows you a basic database table.

State Name Abbreviation Capital State Since
Alabama AL Montgomery 1818
Alaska AK Juneau 1959
Arizona AZ Phoenix 1912
Arkansas AR Little Rock 1836
California CA Sacramento 1850
Colorado CO Denver 1876
Connecticut CT Hartford 1788
Delaware DE Dover 1787
Florida FL Tallahassee 1845

Figure 16-1:
A basic database table.
Figure 16-1 shows a table that contains information about U.S. states: the two letter abbreviation, the name of the state, its capital, and when it became a state.
Organizations use relational databases heavily. For example, accounting systems operate on top of relational databases. Relational databases are commonly called Online Transaction Processing (OLTP) systems.
Relational databases contain a lot of information because so many databases exist. Many software vendors provide relational databases, so they come in many different proprietary flavors. People like to analyze the useful information contained within these OLTP systems, taking advantage of what they can learn from all that data. But relational databases are optimized for transaction processing, not analysis. If you’ve ever tried to wade through a sea of database tables to put together a query for a report, you know what we mean.
Data warehouses, sometimes called data marts, were created to put all this data from all these different flavors of databases together to make the data easier to use. (If you want to find out more about data warehouses, we recommend Data Warehousing For topic, by Alan R. Simon.)
Data warehouses take vast volumes of information for multiple databases and put all that data together into one big data warehouse, which is then used to analyze this information. The analysis is called online analytical processing (OLAP). OLAP systems are optimized for analysis, whereas OLTP systems are optimized for transaction processing.
OLAP systems use something known as a multidimensional model for expressing data. The multidimensional model makes accessing the data fast and flexible. One enabled feature of these OLAP systems is the ability to create queries on the fly because of the speed and flexibility of the multidimensional model. Business intelligence (BI) systems sit on top of data warehouses, making all this data available for use to business users.
But the multidimensional model is more than the ability to slice and dice information. The multidimensional model is inherently flexible, allowing for flexible access to information rather than the more rigid formats of relational models. Business-intelligence software shows the value of the multidimensional model.

Getting a grip on the model

XBRL Dimensions is a standard approach to modeling XBRL information that is easy to get into and out of the multidimensional model. You need at least a basic understanding of the multidimensional model in order to understand XBRL Dimensions. The multidimensional model basically breaks data into two components: the values themselves, called measures, and the dimensions of those values.
A simple example can help you come to grips with the multidimensional model. Figures 16-2 and 16-3 show sales information the way you might see it on a report printed on a piece of paper or one of those electronic pieces of paper, such as an HTML page or a PDF page.
The analysis in Figures 16-2 and 16-3 shows two breakdowns of the same information. Figure 16-2 shows a breakdown by product group and then by region; Figure 16-3 shows a breakdown by region and then by product. Note that the Grand Total of both breakdowns of the analysis is exactly the same. The breakdowns are the same information presented in two different ways.
Only one value (or measure), Sales, is shown in the analysis. That value has three dimensions: region, product, and period. More dimensions, such as the company reporting the information and the currency in which the information is reported, actually exist, but those dimensions are the same for all values in both breakdowns, so they seem somewhat invisible to you.
The analysis in Figures 16-2 and 16-3 is presented to you here on paper; that physical presentation is static and hard to change. You can present this analysis in another way, the pivot table, which allows a user to dynamically pivot the data across it’s dimensions. Many business people are familiar with the pivot table. Figure 16-4 shows a Microsoft Excel pivot table that expresses the same information from Figures 16-2 and 16-3.

Breakdown by Product, by Region (thousands of Euros) Product Region 2003 2002 2001
Pharmacueticals Asia
US and Canada Other Regions
2,864 5,317 5,568 1,147 2,471 4,732 5,527 1,715 2,009 4,233 4,576 1,690
Sub Total 14,896 14,446 12,507
Generics Asia Europe
US and Canada Other Regions
1,616 1,508 489
634 1,383 1,660
503 1,359 1,378
Sub Total 4,420 4,567 4,158
Consumer Health Asia Europe
US and Canada Other Regions
1,457 2,834 2,765 767 1,263 2,592 3,074 1,340 1,025 2,462 2,570 1,365
Sub Total 7,823 8,270 7,421
Other Asia Europe
US and Canada Other Regions
895 1,790 1,673
1,398 2,746 3,225 1,154 1,315 2,826 3,038 1,200
Sub Total 4,899 8,523 8,379
Grand Total 32,038 35,805 32,465

Figure 16-2:
Breakdown by product, then by region.

Breakdown by Region, by Product (thousands of Euros)
Product Region 2003 2002 2001
US and Canada Consumer Health Generics Pharmaceuticals Other Products 2,765 1,508 5,568 1,673 3,074 1,660 5,527 3,225 2,570 1,378 4,576 3,038
Sub Total 11,515 13,486 11,562
Europe Consumer Health Generics Pharmaceuticals Other Products 2,834 1,616 5,317 1,790 2,592 1,383 4,732 2,746 2,462 1,359 4,233 2,826
Sub Total 11,557 11,453 10,879
Asia Consumer Health Generics Pharmaceuticals Other Products 1,457 807
2,864 895
1,263 634 2,471 1,398 1,025 503 2,009 1,315
Sub Total 6,023 5,766 4,852
Other Regions Consumer Health Generics Pharmaceuticals Other Products 767 489 1,147 540 1,340 890 1,715 1,154 1,365 918 1,690 1,200
Sub Total 2,943 5,101 5,173
Grand Total 32,038 35,805 32,465

Figure 16-3:
Breakdown by region, then by product.

Pivot table breakdown by product and then by region.
Figure 16-4:
Pivot table breakdown by product and then by region.
The pivot table looks slightly different than the paper-based analysis shown in Figures 16-2 and 16-3 due to its formatting. If you note the grand totals, you can see that the information is the same, only presented slightly differently. You have, again, a breakdown of sales by product and then by region for the periods 2001, 2002, and 2003. The nice thing about pivot tables is that you can easily pivot the data using the drop-down list boxes to show it by region and then by product, as shown in Figure 16-5.
Pivot table breakdown by region and then by product.
Figure 16-5:
Pivot table breakdown by region and then by product.
Although using static paper in a topic makes getting the full experience of a pivot table difficult, part of a pivot table’s value is that you can pivot data across different dimensions, presenting the data in different ways to meet the different needs of information users.
For both the Excel pivot table and for the paper report, Figure 16-6 shows what the data used to generate this information actually looks like.
The actual information that supplies both pivot tables.
Figure 16-6:
The actual information that supplies both pivot tables.
When people like U.S. SEC ex-Chairman Christopher Cox talk about interactive data, they’re talking about the ability to do things like pivot data in this manner — that’s part of the interactive nature that XBRL helps create. XBRL separates the data itself and the presentation of the data, freeing users of the information to present the information as they see fit.
Most people don’t really think about it, but pretty much all information is multidimensional. Paper is okay for working with one, two, and maybe even three or four dimensions. But as the number of dimensions increases, the more complicated it is for the information to be effectively expressed on a two-dimensional piece of paper.
Computers don’t have such limitations. Pivot tables, and other tools for expressing information, can leverage all sorts of capabilities provided by computer applications to communicate information. This lack of limitations is why the multidimensional model is so powerful — it provides you with flexibility. No longer does information need to be locked into the single presentation format that the information creator used to express the information; instead, users of information, if it’s expressed in this flexible manner of the multidimensional model, are free to reformat the information as they see fit.
A cube is a common way of looking at multidimensional information. The cube in Figure 16-7 provides a good metaphor for understanding the multidimensional model.
A cube of data.
Figure 16-7:
A cube of data.
Figure 16-7 uses this common abstraction, which we use to explain multidimensional concepts. You may recall from school the three axes (dimensions) shown in this cube: the X axis (from left to right), the Y axis (from top to bottom), and the Z axis (front to back). In the cube in Figure 16-7, the X axis covers the periods 2001, 2002, and 2003; the Y axis covers the regions All Regions, US and Canada, Europe, and so on; and the Z axis lists products, such as All Products, Pharmaceuticals, Generics, Consumer Health and Other.
A cube simply allows you to visually comprehend the relationship between the information; it’s only an abstraction to help explain the model. If you were to introduce more axes, you’d need more dimensions, which would be hard to express in a graphic like this. 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; these locked views are commonly referred to as slices of the information. You can break the larger cube into cells. Each cell is an intersection between a period, a region, and a product for the concept Sales. The shaded cell in Figure 16-7 represents sales for the period 2002, the product pharmaceuticals, for all regions.

Grasping the basics of XBRL Dimensions

XBRL Dimensions provides a number of features for those using XBRL:
Model multidimensional information: XBRL Dimensions provides the ability to model information within an XBRL taxonomy using the multidimensional model. XBRL Dimensions allows users to model hypercubes (a.k.a. cubes, or data cubes), the dimensions (axes) of those cubes, domains of the dimensions, and members of the domain. You can also model the primary items (a.k.a. concepts) that exist within a hypercube. XBRL Dimensions supports hierarchies within this dimensional information.
Express contextual information about a business fact within an XBRL instance: XBRL Dimensions allows for the expression of information about a business fact being reported within an XBRL instance. This information, which amounts to metadata, is articulated within a context element entity <segment> or <scenario> element.
Articulate constraints on contextual information: XBRL Dimensions provides the ability to articulate constraints with which an XBRL instance creator must comply. The XBRL taxonomy tells you what the <segment> and <scenario> portion of contexts can and can’t contain— it controls what’s allowed.
Validate contextual information against constraints: XBRL Dimensions provides the ability to validate an XBRL instance against established constraints expressed within an XBRL taxonomy.
Extending contextual information: XBRL Dimensions provides a formal, consistent, specified approach to extend dimensional information. Just like you can add concepts of an XBRL taxonomy, so, too, can you extend the contextual information such as adding hypercubes, dimensions, domains, members, or primary items.

XBRL Dimensions uses specific terminology. Here’s the key terminology related to XBRL Dimensions:

Hypercubes: In XBRL, a hypercube is similar to a multidimensional model cube. Hypercubes bring together a set of dimensions and primary items (which is really a dimension).
Dimension: In XBRL, a dimension is equivalent to a multidimensional model dimension.
Domain: In XBRL, a dimension has a domain, which you can think of as the total dimension, an aggregation of all the members, should that be appropriate. Dimensions don’t need to have totals, but they can, though, if you need to express them.
Member: In XBRL, a member is similar to an multidimensional member.
Primary item: In XBRL, the term primary item is used to mean member as defined by the multidimensional model.
All/Not all: XBRL Dimensions uses Boolean algebra and the All and Not All relations to create any set of allowable members a user might need within a dimension. With a combination of All and Not All, you can express pretty much anything that needs to be expressed. This allows XBRL taxonomy creators to articulate that certain specific cells should never be used or have values within an XBRL instance.
Explicit member: An explicit member is a member defined within an XBRL taxonomy and is literally explicitly defined.
Typed member: A typed member, or implicit member, is implicit. These are defined within an XML Schema rather than within an XBRL taxonomy. Typed members provide for additional flexibility in creating members.
Default Dimension: A primary item can participate in more than one hypercube, each of which has a different set of dimensions. Default dimensions take this into consideration, enabling the expression of the correct dimensional information for each hypercube in which a primary item participates.
Typed members have some issues that you should be aware of if you intend to use them. Simple typed members are generally okay, although you can’t express hierarchies with simple typed members. Avoid complex typed members, if possible, for several reasons. First, complex typed members can have literally any XML content model, making an interface required for creating them quite complex. Second, complex typed members can’t express hierarchies — they’re flat, meaning that you can’t express relations between typed members like you can explicit members. Third, XBRL Formula doesn’t work nearly as well with complex typed members as they do with explicit members or simple typed members.
Default dimensions have some issues you should be aware of if you intend to use them. Most issues relate to uncommon and complex uses of default dimensions. One particular issue occurs when you use XBRL Formula validation. Again, beware! If you’re careful and conscious of what you’re doing, you can use default dimensions safely. If you don’t want the trouble, stay away from default dimensions or hire a good consultant.

Expressing Business Rules Using XBRL Formula

XBRL Formula enables the expression of business rules within an XBRL taxonomy, exchange of those business rules within a standard format, and validation of XBRL instances against expressed business rules. What makes business rules so interesting, however, is the fact that now with XBRL, all that information is in a structured format and therefore you can express business rules and get computers to enforce those rules. When information is unstructured, humans have to enforce these rules using manual effort.

Getting a grip on business rules

A formal statement that defines or constrains some aspect of a business that is intended to assert business structure, or to control or otherwise influence the behavior of the business
A way of expressing the business meaning (semantics) of a set of information
A formal and implementable expression of some business user requirement
The practices, processes, and policies by which an organization conducts its business
For more information about business rules, see the Business Rules Group at
Business rules exist in the form of relationships between pieces of business information. Some examples can help you better understand exactly what they are:
Assertions, such as the balance sheet balances or Assets = Liabilities + Equity
Computations, such as Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other
Process-oriented rules, such as “If Property, Plant, and Equipment exists, then a Property, Plant and Equipment policies and disclosures must exist.”
Regulations, such as “The following is the set of ten things that must be reported if you have Property, Plant and Equipment on your balance sheet: deprecation method by class, useful life by class, amount under capital leases by class . . .” and so on
Instructions or documentation, such as “Cash flow types must be either operating, financing, or investing.”
The ability to express business rules is probably the single most powerful feature of XBRL, other than the fundamental ability to express business information in a standard structured format.
You can define business rules in many ways; there really isn’t one standard definition. Rather than trying to create just one definition here, we provide you with several definitions of business rules:

The components of XBRL Formula

Functions: A collection of common functions used to obtain information out of an XBRL instance in support of XBRL Formula or other purposes.
Formula: Allows for the expression of formulas (a.k.a. business rules). You can even express formula results in the form of an XBRL instance, enabling the chaining of different XBRL instances and XBRL Formula into a work flow.
Variables: Allow for the definition of variables that a formula then uses.
Filters: Establish filters for working with subsets of fact values of different types from one or more XBRL instances. Various types of filters correspond to useful filters when working with XBRL instances.
Consistency assertions: Check a computed item to an existing source item. Allow for the evaluation of whether the source and the computed item are consistent. These assertions allow for the verification of the accuracy of XBRL instance information.
Value assertions: Check as a computation. Allow for the creation of values that you can subsequently use for further processing, which may include creation of new information within an XBRL instance.
Existence assertions: Check for the existence of a source item. Allow for verification of existing information and further processing.
Validation: Verifies value assertions, consistency assertions, and existence assertions. Extends the functionality of the three different types of assertions.
Generic labels: Provide for the labeling of any XBRL element, attribute, or value. Labeling is useful in providing human-readable information or documentation for a formula, but you can also use it for other purposes.
Generic references: Provide for the references of any XBRL element, attribute, or value. Generic references are useful in providing human-readable information or documentation for a formula, but you can use them for other purposes, too.
XBRL Formula is part of the XBRL family, but it’s actually a family in and of itself. XBRL Formula is a set of modular specification that works together — it’s not just one specification. These specifications are separate for the same types of reasons the XBRL family of specifications is modular — so that you can use what you need and ignore the rest.

Here are the members of the XBRL Formula set of specifications:

All these specifications work together to support the expression of information in the form of business rules that document relationships. You can use this information to communicate such relationships from the producers to the consumers of this business information. These business rules help enable effective information exchange by ensuring validity of the information being exchanged.

Separating business rules from applications

Knowing what business rules are is important because they’re extraordinarily useful for business information exchange. But what is even more important is how business rules were created and used in the past, and how they’ll be created and used in the future.
You may remember when someone building a computer application had to also build a place to store the application’s data. Well, those days are over with the advent of the standard relational database management system (RDBMS) and structured query language (SQL) for accessing information within a database. Basically, the database is now separate from the application, so you can buy a standard SQL database and use that database to store data, rather than every software vendor building its own data storage scheme. This separation between the database and the application occurred in the 1980s.

The separation of business rules from the actual application likewise provides efficiencies:

Rather than paying programmers to update rules, business users can update the rules themselves, saving both time and money.
Rather than having programmers create validation for each thing they want to validate (called one-to-one programmatic validation), you can use a business-rules engine to do validation (many-to-many rules-based validation). Further, these rules engines can hide much of the complexity of expressing rules from the business users.
Because the business rules are separated from the application or database, creators of information sets can use the business rules established to constrain that information set. Creators can then exchange those business rules with users of the information set, which helps analysts understand the information. Both creators and analysts use the same set of business rules, which makes things clearer to both creators and consumers of the information.

Automating workflow

After the business rules are separated from applications, applications can exchange them. Expressing these business rules in a standard way has additional advantages. Because you can exchange the rules with others, for example, you can

Use the rules to explain the information you’re collecting

Determine which information needs to be collected from those creating XBRL instances
Validate the XBRL instance information prior to it being submitted
Automatically determine which information collection forms should be used by which type or quality of entity submitting information
These business rules promote an understanding of business policies and procedures, facilitate consistent decision-making, and force order to rules and policies because they’re clearly expressed. And it’s all done with increased flexibility because of the separation of the processing logic from the rules and the resulting ability of the business users to control the processing logic easily without understanding programming.

Creating Human-Readable XBRL Information Using XBRL Rendering

Although automated processes can consume the information contained in XBRL instances, humans many times need to consume this information, too. Although computer processes read the information, they don’t need nicely formatted presentation formats to do their reading. Computers prefer easy-to-digest angle brackets — all that markup stuff humans find challenging to come to grips with. Humans, on the other hand, do need nice, easy-to-read formats to consume this information.
The XBRL Rendering specifications help provide the ability to render XBRL instance information so that humans can consume that information. You can obtain additional information relating to rendering specifications from XBRL International at www.xbrl.org/Specifications.

Getting a grip on rendering

One-to-one renderings: If each creator of an XBRL instance had to create his own way to render that XBRL instance, it would be bad for two reasons. First, creating one-to-one renderings is time-consuming and therefore costly. Second, if you want to compare information across XBRL instances and each XBRL instance is rendered differently, comparison across XBRL instances can be quite challenging.
One-to-many renderings: What we really want is one-to-many renderings. One-to-many means that one template is created that expresses how to render the fact values of an XBRL instance created with a certain taxonomy or set of taxonomies. If extensions aren’t allowed, this task is actually relatively trivial. However, if extensions are allowed, it makes rendering more challenging. You can easily create one-to-one renderings, but if you can’t share them between software tools, they really don’t provide what you need.
Standard for one-to-many renderings: The issue that rendering specifications need to solve is the ability to create a one-to-many set of formatting information that allows for renderings in a variety of formats, such as HTML, PDF, Word, Excel, and so on, that software applications can share, a standard.
Rendering XBRL isn’t really that much of a challenge. You can use many mechanisms for rendering XML-type information into formats consumable by humans. XSLT, as an example, can transform one type of XML into another type of XML or other formats, such as HTML, PDF, DocBook, or even Microsoft Word and Excel formats, which are also XML in their 2007 versions. XBRL is easy to render because each fact value is easily identified within an XBRL instance.
However, you generally need to take an extra step to render XBRL information. In Chapter 2, we discuss a content model that the creators of XBRL decided not to use — the one that most other XML languages use to help render their XML into more human-readable formats. Well, we need to get that information back. XBRL generally doesn’t use the XML content model; this information on relations is stored in linkbases. (Refer to Chapter 4 for more information on linkbases.) Having to get this rendering information from linkbases isn’t a problem because XBRL processors can help you. But, there are some challenges:

The components of XBRL rendering

Inline rendering (HTML version): For formatting XBRL-based information within an HTML document for human consumption, but also for consumption by automated processes
Inline rendering (other formats): For the formatting of XBRL-based information within other types of documents (other than HTML) that allows for human or automated consumption
Rendering linkbase: For connecting rendering information to an XBRL taxonomy (for example, providing HTML information that explains how information expressed within an XBRL instance for that specific XBRL taxonomy should be rendered); different rendering formats are supported

Maintaining XBRL Taxonomies and XBRL Instances Using XBRL Versioning

Things change. This adage holds true for things expressed in XBRL, be it an XBRL taxonomy or an XBRL instance. XBRL Versioning enables the communication of these types of changes in a global standard way to both humans and to computer processes. XBRL Versioning helps publishers of XBRL taxonomies communicate changes to their taxonomies and also helps users of those taxonomies understand how a taxonomy they use has changed. Therefore, taxonomy users can determine what adjustments, such as mappings to the XBRL taxonomy, the users need to make to their systems.
Communicating these changes is important because it enables the possibility of writing computer software applications to update systems for many, but not all, of these types of changes, which saves you time and money. XBRL Versioning may not be sexy, but it’s helpful. (For more information relating to XBRL Versioning, see www.xbrl.org/SpecCRs.)
The human rendering of XBRL instance information has several different aspects covered by the different components that comprise the set of XBRL Rendering specifications:

Getting a grip on versioning

Changes between taxonomy versions: XBRL U.S. has stated that it will change the US GAAP taxonomies each year. When a new taxonomy is released, you need to understand the changes made to the taxonomy.
Changes to your mappings: Coordinating the concepts you use within your internal business systems with the concepts used within an XBRL taxonomy is referred to as mapping. During the mapping process, you create a way to link your internal systems to, in this case, an XBRL taxonomy. Say that you’ve set up your systems to work with a specific XBRL taxonomy. However, a newer version of that XBRL taxonomy has added concepts, removed existing concepts, and made changes to relations and resource networks within the taxonomy. You need to update your systems to reflect these changes.
Analysis and comparisons: Suppose that an entity releases information in one year based on one XBRL taxonomy and in the next year uses a new version of the XBRL taxonomy. Then imagine that you need to do a comparison between the two XBRL instances that use two different versions of the same XBRL taxonomy. Consider what a comparison may look like over a five-year period, which is common period used for financial-reporting types of analysis.
You get the idea that changes can cause issues. Take a look at the specific types of things that may change within an XBRL taxonomy or XBRL instance:
DTS or taxonomy-level changes: Changes to a DTS may include the addition of new concepts to the taxonomy schema or the removal of concepts. The addition or removal of networks may occur.
Concept-level changes: A concept may have changes to its name or changes to any of the various attributes of that concept.
Relation changes: The addition or removal of relations or changes to existing relations may occur.
Resource changes: The addition or removal of resources or changes to existing resource information may occur.
Instance changes: Between two XBRL instances, things can change. For example, changes to an XBRL taxonomy concept changes the name of the fact value used within an XBRL instance (which comes from the XBRL taxonomy).
Versioning relates to changes in XBRL taxonomies and XBRL instance. For example, consider the following possible types of changes:

The components of XBRL Versioning

‘ Versioning Specification Part 1 – Content: Describes the types of changes to concept definitions and resources that can exist between all the files that make up a DTS. In most situations, changes between DTSs would be between two consecutive versions of the same set of XBRL taxonomies. Basically, versioning content explains the things that have changed.
‘ Versioning Specification Part 2 – Syntax: Prescribes a syntax for creating reports of changes described in Part 1. This syntax enables the creation of computer applications to read these changes and automate many processes relating to updating systems for such changes. For example, you can now create automatically updated mapping tables that communicate taxonomy changes.
‘ XBRL Infoset: Helps versioning work correctly. It formally describes the content of a DTS without regard to the syntax used to express this syntax. This specification allows for consistent serialization of XBRL DTS information so that changes can be accurately identified. Technical people need this specification to make versioning work correctly, but business people don’t generally need to understand it. For more information on XBRL Infoset, see www.xbrl.org/Specification/ Infoset/PWD-2 00 9-02-04/infoset-PWD-2 0 09-02-04.html.

Creating Custom Resources and Relations Using Generic Linkbases

The Generic Linkbase is a specification for creating custom resource type or relations type networks within linkbases (see Chapter 4). You can use these resources and relations to extend the power of XBRL. For example, XBRL International used the Generic Linkbase Specification to create the XBRL Formula specification.
Like other XBRL modules within the XBRL family, the XBRL Versioning specifications are a set of specifications that work together to provide the needed functionally. In XBRL Versioning’s case, here are the components:

Getting a grip on Generic Linkbases

Generic Linkbase Specification: Find the specification itself at www.
XBRL Formula Specification: The XBRL Formula Specification uses the Generic Linkbase Specification. A great way to learn about using this type of functionally is to explore how the XBRL Formula specification used it. You can basically use XBRL Formula to reverse-engineer how to create your own linkbase for some another purpose.
Link Role Registry: The Link Role Registry (LRR) allows you to define and use specific extended link, arc, and resource roles for various purposes and use definitions others have created. If you’re into the Generic Linkbase specification, see www.xbrl.org/LRR.
The need that the Generic Linkbase Specification serves is twofold. First, it allows XBRL International to not have to write a new linkbase specification every time it creates a new XBRL module that requires linkbases, such as XBRL Formula. Second, it allows others to create XBRL-compliant linkbases for any number of other purposes. Using the Generic Linkbase Specification as a foundation to build on provides leverage, allowing things built in a similar manner to be more quickly implemented in software applications with less work.
For example, the Generic Linkbase Specification was used to create the XBRL Formula linkbases. While an XBRL processor may not understand the specifics of a linkbase you’ve created, it does provide for a large amount of leverage. This standard way of connecting other nonstandard information to your XBRL information makes tasks you perform significantly easier.
The Generic Linkbase Specification serves another purpose. Linkbases can provide human-readable documentation, references, or other resources to any XBRL element, attribute, or value. For example, they can provide a label that describes a context contained within an XBRL instance in any number of languages using a Generic Linkbase. You can then use this information, say, within a software application to provide a better user experience, allowing users to not have to deal with technical stuff.

XBRL Generic Linkbases components

Unlike many of the other XBRL modules, the Generic Linkbase Specification is one simple specification. It has only one part. However, a few things can help you understand and make use of Generic Linkbases:

The XBRL Global Ledger Taxonomy

The XBRL Global Ledger taxonomy (XBRL GL) is really in a class by itself. Not really a module, but more than a taxonomy, XBRL GL serves a specific need. Integration of two business systems may be anywhere between a simple copy-and-paste task all the way up to a complex series of ETL (Extract, Transform, Load) tasks. XBRL GL exists to make these information exchanges easier for accounting-type business systems.

Getting a grip on XBRL GL

XBRL GL is a modular set of taxonomies, specification-type guidelines, and best-practices documents. XBRL GL documents and prescribes XBRL GL Instance Standards and a GL Taxonomy Technical Architecture. Its purpose is to provide a standard (canonical) format for representing and exchanging information commonly found in accounting and business systems. Using XBRL GL, organizations can eliminate many of the difficulties and complexities traditionally encountered when exchanging common types of business information. Users of XBRL GL benefit in terms of reduced costs, increased timeliness of information, improved information quality, and improved data usability and reusability.
XBRL Global Ledger is an XBRL taxonomy created by the members of XBRL International. The best way to describe XBRL GL is to explain what you can use it for:
Standard integration format for software vendors to create journal entries for import or export to or from a general ledger system
Integrating branch office feeder systems with consolidated systems in the central office for accounting consolidations, budgeting and forecasting, or other reporting functions
Exchange of information used for accounting write-up work, compilations, review, or audits between a client and CPA
Creation of internal or external audit schedules for maintaining an audit trail
Moving data from one accounting system to another accounting system during a change in accounting systems
Enabling drill down from summarized financial reporting or accounting information into its detail; or aggregation from the detail to the summaries
Summarizing financial information that will be used in higher level accounting reports or statements.
The focus of XBRL GL is on common types of business information commonly found in the business systems that operate in most organizations. Examples of these systems include the general ledger, chart of accounts, accounts receivable subsystems, accounts payable subsystems, payroll subsystems, fixed asset subsystems, inventory subsystems, job costing subsystems, and so on. You get it: accounting systems, or ERP systems, as we call them these days.

You can use XBRL to create what XBRL GL provides: Proof is that XBRL GL

exists, and it’s 100-percent XBRL. You can even create your own XML language for doing what XBRL GL does. You can do such integrations in several different ways. These integrations aren’t sexy or exciting, but they’re needed by literally every organization that has more than one business system. XBRL GL is the way, the canonical approach, that’s being accepted around the world (or at least probably will be) for representing information exchanged between business systems.
Could information be transferred between business systems prior to XBRL GL existing? Of course, it could. Everyone would simply come up with his way and create countless import and export applications to get accounting information from one place and put it someplace else. Why was everyone creating it his own way? Well, because the canonical way did not exist. Now it does. Hallelujah, brother! Accountants everywhere are singing and dancing in the streets.

Accountants, taxes, and XBRL GL

Only two things in life are certain: death and taxes. Tax collectors around the world have shown a lot of interest in XBRL GL. Government tax administrators around the world have been using proprietary formats for exchanging information — or even worse, manually exchanging information on paper. But the tax guys are becoming more efficient thanks to XBRL GL.
Around the world, tax administrators are collaborating to create more standard formats, rather than proprietary formats, to exchange tax-related information. This collaboration is important because, for example, the U.S tax-collecting agency, the Internal Revenue Service (IRS), has tax treaties with more than 100 other countries for exchanging tax information for various administrative reasons.
These tax administrators have generally agreed to use XBRL as a standard format for exchanging information with taxpayers and as a standard tax audit file format. These tax guys and their e-filings and e-audits are pretty progressive. Maybe this tax and accounting stuff isn’t that thrilling, but administering these things is pretty important.

Next post:

Previous post: