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 http://www.xbrl.org/uk/ 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.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.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.