Posts Tagged "taxonomy architecture"

1. Because the filing program supported by the base taxonomy is an open program – which means that it allows, or even requires, filings based on a filer-specific extension to the base taxonomy. We will refer to this kind of extension as a “public” taxonomy extension;
2. Because the owner of the extension intends to leverage a publicly available taxonomy internally, for purposes that are not directly or necessarily related to a filing program or to the purposes for which the base taxonomy is created and maintained. We will identify this kind of extension as a “private” taxonomy extension.

If the taxonomy extension is created for the purpose of filing XBRL reports within an open XBRL filing program, the regulator receives and accepts the extension together with the filings. The rules for the creation of a valid public taxonomy extension are set by the regulator and designed to make extensions consistent with the processes of reception/consumption of the filings. It is also important to remember that the XBRL Specification supports the creation of extensions in a way that makes it possible to easily separate the base taxonomy from its extension – see the previous XBRL FAQ on the topic. A taxonomy extension never changes or deletes anything in the base taxonomy; it only adds something new to what is in the base taxonomy, or prohibits something that is already there. This mechanism makes it easy for the regulator to either ignore or consume selectively the extension or parts of it.

If the extension is created by an organization that intends to leverage the base taxonomy internally and customize it for a specific internal process or purpose, the owner of the base taxonomy is not even aware that the taxonomy has been extended. It is totally possible that the organization that creates the private extension is not even subject to a regulatory mandate that requires the use of the base taxonomy being extended – the taxonomy just happens to be a valuable, authoritative and free knowledge base of reporting concepts, documentation and related resources that are useful to the organization internal processes. Even if the organization is required to use the base taxonomy for regulatory compliance it is easy to create instances with only the subset of data that is valid against the base taxonomy for the purpose of eFiling, and create instances that include extension data for other internal purposes.

The release of a new version of the base taxonomy requires the release of a new extension. The content of the extension can remain the same, or change because of increased scope or to leverage the new resources added to the base taxonomy. Designing the architecture of the extension and the guidelines for its maintenance in a way that make it easy to adapt to the evolution of the base taxonomy is key for a sustainable life cycle of the taxonomy extension and for the efficiency of the processes that it supports.

The fact that private extensions to XBRL taxonomies are created even when a regulatory program does not allow extensions is a reality and a key part of the value proposition of XBRL for the regulated community. Regulators should keep this fact in mind when designing their taxonomy architectures, keeping them as simple as possible to make extension easier and providing information and guidelines for an effective extension to facilitate the process.

From a technical standpoint, there is no difference between XBRL GL and other XBRL taxonomies, such as the IFRS taxonomy, the US-GAAP taxonomy, or the Standard Business Reporting (SBR) taxonomies. Each XBRL taxonomy has a different architecture – basically, a set of rules that defines the way in which the various technical tools and features defined in the XBRL Specifications must be used within the taxonomy itself. The reason why a taxonomy architecture is necessary is that not all the technical features defined in the XBRL Specifications are always all relevant in all situations, and different types of information being represented by a taxonomy require different subsets of features that are more suitable to represent them. The taxonomy architecture identifies the subset of XBRL technical features that must be used to create and maintain a specific taxonomy, and provides guidance on how to use them. XBRL GL, like any other XBRL taxonomy, has its own architecture, consistent with the type of information that it represents and the requirements that it needs to meet in order to support its business purpose.

From a business standpoint, each XBRL taxonomy is designed to achieve a certain purpose. The business purpose of many XBRL taxonomies is to support the creation of specific reports, such as “financial statements according to the International Financial Reporting Standards (IFRS)” or “financial statements according to the US GAAP.” Others have a broader business purpose. For example, the purpose of the Standard Business Reporting (SBR) taxonomy is “supporting all the reports that businesses must submit to the participating agencies in the Australian Government.”

The XBRL GL taxonomy is provides a standardized representation of the business information found in any accounting and operational software application, and of the rules used to populate end reports (typically represented by other XBRL taxonomies) with that information. In practice, this means that the business purpose of the XBRL GL taxonomy is to enable the creation of standardized, application-independent and purpose-independent processes to access, monitor, analyze, and report on business data.

The term “extension” normally conveys the idea of augmenting something, but as far as XBRL taxonomies are concerned, this is not necessarily true. As mentioned above, not only adding to, but also changing or removing something in a taxonomy, for example a label, is defined as an extension. The reason for this is that since the user performing the change or the removal is not the owner of the taxonomy, the change or the removal cannot obviously happen in the original taxonomy, nor it can affect other users of the same taxonomy.

When a user creates an extension of a taxonomy, the process starts with the creation of a new, empty taxonomy, of which the user is the owner. The taxonomy to be extended (generally called the “base taxonomy”) is then imported into the extension, and the user can now:

1. Add new elements and resources in the extension taxonomy, creating them in a way that makes it easy to identify them and keep them separate from the elements and resources defined in the base taxonomy;
2. Delete resources defined in the base taxonomy, using a mechanism defined in the XBRL 2.1 Specification called “prohibition” that leaves the original resources intact in the base taxonomy but effectively hides them in the extension, as opposed to simply deleting them;
3. Change resources defined in the base taxonomy, by prohibiting the original resource as described in point 2 and adding a new resource that replaces it, modified as desired.

The extension mechanism guarantees the integrity of the base taxonomy and the ability to customize it while still being able to identify what is defined in the base taxonomy and what in the extension. This is important for several reasons:

• Regulators who run open XBRL reporting environment allow (and sometimes require) filers to create and submit extensions. These regulators are the owners of the XBRL taxonomies that support those open reporting environments, and will generally set rules for the creation of valid extensions. These rules have among their objectives to allow the regulator to easily separate the base taxonomy from users extensions;
• Users who extend a taxonomy, either to use it in an open regulatory initiative or to leverage It as a valuable knowledge base for internal purposes not necessarily related to the original purpose for which the taxonomy was created, will want to update their extension to new releases of the base taxonomy as they become available. The extension mechanism is a key enabler of this process.