Requirements for Taxonomy Packages 1.0

Requirements Document 14 January 2015

Copyright © 2013, 2014, XBRL International Inc., All Rights Reserved.

This version:
Trevor Pyman, IRIS Business Services <>
Paul Warren, XBRL International Inc. <>
Víctor Morilla, Banco de España <>
Hugh Wallis, IBM <>


Circulation of this Requirements Document is unrestricted. Other documents may supersede this document.


This document describes the requirements for a standardised format for the distribution of XBRL Taxonomies as single file archives containing additional meta-data in order to enable easier configuration and use of taxonomies within XBRL software.

Table of Contents

1 Introduction
2 Use Cases
2.1 Australian SBR
2.2 UK GAAP Taxonomy
2.3 European Banking Supervision
3 Requirements
3.1 Remappings
3.2 Entry points
3.3 Taxonomy meta-data
4 Out of scope requirements
4.1 Valid identifier schemes
4.2 Taxonomy validity periods
4.3 Taxonomy signing/checksums
4.4 Instance documents


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

1 Introduction

Taxonomies are a key part of XBRL. They typically consist of many files, hosted on a website somewhere, which are then referenced by the instance documents or extension taxonomies that use them. This creates two practical problems for people working with taxonomies.

  1. Finding the Entry Points; and
  2. Working Offline

For convenience, XBRL taxonomies are often distributed as archive (typically ZIP) files, with accompanying human-readable documentation describing which of the component files should be considered entry points. This requirements document proposes standardisation of such documentation in a structured format, allowing compliant tools to identify the entry points automatically and to present them to the user using a suitable interface.

XBRL taxonomies are typically published on publicly available web servers, and then referenced by instance documents using an absolute URL. This creates problems for users of the taxonomy:

Many users prefer to work offline with local copies of the taxonomy contained in the archive files referred to above and many XBRL tools already provide mechanisms for working with such files more conveniently. achieving this. Adoption of XBRL is likely to be improved if we can define a standard mechanism for automatic configuration for offline work.

The standardisation of the format to be used for taxonomy distribution provides an opportunity for the inclusion of additional items of meta-data about the taxonomy as a whole. Possible meta-data items are discussed in the requirements below.

2 Use Cases

2.1 Australian SBR

This taxonomy utilises a two-tier approach wherein all reportable business concepts are described in a “Definitional Taxonomy” and then reused across a multitude of entry point taxonomies specific to each reporting obligation, called “Report Taxonomies”. The Definitional Taxonomy only has label and reference linkbase files associated with the schemas as its purpose is simply to describe the business concepts. The Report taxonomies add the structure and relationships required by individual reporting obligations, as well as (optionally) additional report specific descriptions and labels. The overall DTS comprises 12,983 files with a total file size of 860 megabytes, 49 megabytes when compressed.

The ZIP package has 29 entry points at the root level (one for each version released since the last annual “baseline” version) and 2 folders, one for the Definitional Taxonomy files and one for the Report taxonomy files.

The Definitional Taxonomy folder contains 29 versions of an entry point schema for everything contained in separate subfolders for:

  1. “Foundation” elements (fdtn) – datatype and custom linkrole definitions;
  2. “Dimensions” (dims) – each dimension item and its associated domain members in 362 separate XSD files, with 362 associated label linkbase files;
  3. “Common Modules” (comnmdle) – schema files describing commonly reused structures – e.g. addresses, names, bank accounts, direct debit instructions, etc
  4. “External” taxonomies (extl) – e.g. IFRS taxonomy imported for reuse; and
  5. “Information Classifications” (icls) – the schema files containing the business concept elements and associated label and reference linkbase files that describe them. These are further split into 8 subfolders based on government information classifications (e.g. “Business and Financial”, “Labour Relations”, “Revenue Collection”, etc. Each of these contain further subfolders for lower level information classes.

The Report taxonomy folder similarly contains 29 versions of an entry point schema for everything contained in separate subfolders for each of the 12 agencies with reporting obligations that can be filed via SBR. Each agency splits the taxonomies into subfolders according to individual preference but at the top level of every folder is at least one (and up to 29) version of an entry point schema that contains everything below it. There are in excess of 400 reporting obligations represented in these folders, each with one or more versions.

As can be appreciated, this is an enormous and very complex DTS. Most often it is consumed offline using local copies of the required version because of its size. Users must rely on their tools to remap the URLs from the original published DTS on the internet to the local server location.

The number of entry point schemas runs into the thousands and the only clue as to their purpose is in highly abbreviated folder and file names or in external documents published separately to the DTS. A standardised mechanism for describing and navigating this DTS would greatly assist those who are trying to consume it and enhance its adoption. The features of a Taxonomy Package specification that would be of most use in this case are:

  1. Remapping absolute internet URLs to local locations;
  2. Identification of entry point schemas as such;
  3. Human-readable descriptions of the contents and purpose of each entry point schema and folder; and
  4. Identification of versions of the same entry point with descriptions of the differences between versions.

2.2 UK GAAP Taxonomy

The UK GAAP, IFRS, Banking and Charities Taxonomies are used by companies to file company reports to the UK tax authority (HMRC) and the UK company registrar (Companies House).

The 2009 release of these taxonomies consists of a ZIP file containing 603 files. Just four of these are intended to be used be used directly when opening the taxonomy in an XBRL tool These are currently documented in four separate Word documents contained within the ZIP file.

The files contained within the ZIP file are also published individually at their canonical locations under the hierarchy. It is often desirable for preparers and other users to work with local copies of the taxonomies, but it is important that when files are prepared and submitted to regulators, they reference the taxonomy files at their canonical web locations rather than the local copies that the user has downloaded.

A standardised mechanism for documenting both entry points and the relationship between canonical location and files contained in the ZIP file would make it easy for tools to present an intuitive interface to the taxonomy and to hide much of the detail associated with configure a tool to use the taxonomy. The features of a Taxonomy Package specification that would be of most use in this case are:

  1. Remapping absolute internet URLs to local server addresses;
  2. Identification of entry point schemas as such; and
  3. Human-readable descriptions of the contents and purpose of each entry point schema and folder.

2.3 European Banking Supervision

The taxonomies currently used for banking supervision in Europe are developed and maintained by different authorities. The European Banking Authority (EBA) is the main institution in charge of the definition of the concepts for taxonomies like FINREP and COREP. National supervisors are able to extend these taxonomies (e.g. financial individual information, statistical information…). EBA taxonomies make use of some auxiliary taxonomy files that are maintained by Eurofiling and used by other European supervisors such as the European Insurance and Occupational Pensions Authority (EIOPA).

The European Banking Authority provides ZIP files with the taxonomy files maintained by this institution. Another ZIP with the same structure is provided with Eurofiling files. It is expected that those institutions extending EBA taxonomies will take a similar approach to distribute their own files. As a consequence, supervised institutions need to deploy the files provided by different authorities in different ZIP files in the production environments.

These ZIP files already include XML Catalog files (a standard developed by OASIS and supported by multiple tools in the market) with remapping information to enable the usage of these taxonomies in a local environment.

The EBA taxonomy currently contains over 6,000 files, and just 10 are intended to be used as entry points. The location of entry points is currently described in two PDF documents distributed with the taxonomy: a "read me" file and a taxonomy architecture document. A standard mechanism for identifying and describing the entry points would allow users to get started using the taxonomy much more easily in any compliant tool.

Because of the distributed nature of the maintenance of these taxonomies, the integration of the remapping information provided in these packages is more than convenient. Banco de España currently uses a master XML Catalog file that points to the catalog files provided by the EBA plus some additional catalog files for the resolution of the canonical location of additional XML files (schema files, XSL transformations…) used in its IT infrastructure. This way, all the XML files are accessible from their canonical location in a secure environment without Internet access. This infrastructure enables the usage of taxonomy files by non XBRL specific tools, for instance, for the generation of documentation by applying XSL transformations.

Some European supervisors store taxonomy files for offline use in relational databases with XML support. The resolution of XML files in these environments is usually performed with the help of URLs with certain schemes that represent the location of a file in the database. In such cases, the integration of XML files accessible through different protocols (file, http, database…) is possible with the use of master catalog files that redirect to additional catalog files in different sources.

The features of a Taxonomy Package specification that would be of most use in this case are:

  1. Standard identification of entry points and its documentation;
  2. Identification of the version of the set of files distributed in a package;
  3. Access to taxonomy files from their canonical locations in secure environments with no internet access;
  4. Integrated access to taxonomy files provided in different packages by different authorities and possibly through different protocols; and
  5. Access to taxonomy files together with other (non XBRL specific) XML files by its canonical location by XML Catalog compliant tools.

3 Requirements

3.1 Remappings

A Taxonomy Package should provide remappings that allow one URL to be substituted for another during URL resolution. The typical usage for this is to allow a public, absolute URL (typically using the "http" scheme [IETF RFC 1738]) to be resolved to a file within a Taxonomy Package. This allows processors to use copies of published taxonomies provided by a Taxonomy Package, rather than retrieving the taxonomy files from the Internet.

3.2 Entry points

A Taxonomy Package should allow authors to provide an ordered list of entry points. An entry point is a set of URLs (although typically only one) that define a logical starting point for the DTS discovery process, as defined in [XBRL 2.1].

It should be possible to provide a name, description and version identifier for each entry point. It should be possible to provide translations of the entry point name and description in multiple languages.

It may be desirable to represent a hierarchy of entry points rather than just a flat list.

3.3 Taxonomy meta-data

It should be possible to provide the following items of taxonomy-related meta-data in a taxonomy package.

  1. Name (mandatory) - a concise, human readable description for the taoxnomy
  2. Version identifier (mandatory) - a string identifying the version of the taxonomy package. No specific format for this identifier should be prescribed.
  3. Description (optional) - a human readable description of the taxonomy.
  4. Link to authoritative reference (optional) - a pointer to an external authoritative reference that supports the description provided. This could be a URL or any other device acceptable to the user and capable of locating this additional supporting material.
  5. Publisher (optional) - the entity responsible for publishing the taxonomy.
  6. Publication Date (optional) - the date of publication of the taxonomy.
  7. Superseded taxonomies (optional) - a list of taxonomies which the current taxonomy supersedes, in order to allow software to guide users to the most recent version of a taxonomy.
  8. Links to versioning reports (optional) - links to XBRL Versioning Reports which document the differences between the current taxonomy and previous versions.

The approach taken to capturing meta-data should be extensible, in order to allow future developments, either independent or as part of an XII standardisation process, to address new requirements. This may include requirements documented as being out of scope for the first release (see below).

4 Out of scope requirements

The following potential requirements were discussed, and determined to be out of scope for the initial release of this specification.

4.1 Valid identifier schemes

XBRL report preparers are required to provide an entity identifier for all facts in the instance document, comprising an identifier scheme, which is a URI, and a unique identifier within that scheme.

There is no standardised mechanism for communicating the set of identifier schemes that are allowed within a filing regime, and taxonomy packages may provide a opportunity for doing this.

This requirement is out-of-scope as there is potential for significant extra complexity, and it could safely be undertaken as a separate piece of work.

4.2 Taxonomy validity periods

Taxonomies typically model a particular version of a business reporting standard, and as such, there are often restrictions on when the taxonomies may be used, based either on the date of filing, or on the period to which the filing relates, or both.

This requirement is out-of-scope as there is potential for significant extra complexity in how such validity periods would be specified and applied, and it could safely be undertaken as a separate piece of work.

4.3 Taxonomy signing/checksums

Taxonomy users may wish to check the integrity and authenticity of a taxonomy, and a taxonomy package provides an artefact that is easier to sign or perform a checksum on than a taxonomy published as individual files on web site.

This requirement is considered out-of-scope as there is nothing XBRL-specific about the requirement: existing checksum and cryptographic signing techniques can be applied to a taxonomy package.

4.4 Instance documents

There are various scenarios in which it may be desirable to include instance documents as part of a taxonomy package. These include where a regulatory filing consists of both an instance document and an extension taxonomy, or where a published taxonomy includes sample instance documents.

This requirement is considered out-of-scope as it was felt that it had the potential to add significant extra complexity. In particular, the Working Group considered that instance documents may need to be created or updated on a different frequency to the taxonomies to which they relate, leading to unnecessary and potentially confusing republication of the taxonomy itself.

Appendix A References

IETF (Internet Engineering Task Force). "RFC 1738: Uniform Resource Locators (URL)"
T. Berners-Lee
, L. Masinter, and M. McCahill.
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2013-02-20"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.

Appendix B 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 (


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 (

Appendix C Acknowledgements (non-normative)

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

Appendix D Document history

12 December 2013Trevor Pyman

First draft created

13 December 2013Paul Warren

Converted to S4S

13 January 2014Víctor Morilla

Added use cases for European banking supervision

19 June 2014Paul Warren

Incorporated additional requirements identified during PWD review period.

24 June 2014Paul Warren

Incorporation of feedback from Hugh Wallis.

Appendix E Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Base Specification and Maintenance Working Group up to and including 14 January 2015. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.