Copyright © XBRL International Inc., All Rights Reserved.
Circulation of this Requirements Document is unrestricted. Other documents may supersede this document.
This document defines requirements for a standardised mechanism for the inclusion of "filing indicators" in an XBRL report, using a syntax that is compatible with the XBRL Open Information Model. Filing indicators allow preparers to make an explicit statement about which data sets, or templates, within a reporting requirement they have intended to complete.
1 Introduction
1.1 Terminology
2 Current approach
3 Requirements
3.1 List of templates
3.2 Uniqueness
3.3 Definition of available templates
3.4 OIM compatibility
3.5 Impact of adoption
3.6 Transformations
3.7 Extensibility
3.8 Co-existence with current syntax
3.9 Utility functions
A References
B Intellectual property status (non-normative)
C Document History (non-normative)
D Errata Corrections incorporated in this document
In a number of filing environments, XBRL is used to report very large, complex and highly-dimensional data sets. For the purposes of managing and defining the reporting requirements, and for report visualisation, the data set is often described in terms of a number of templates. Filers will provide an XBRL report that contains data for one or more templates, with different entities required to report different templates based on their individual circumstances. Rather than modelling these templates as discrete forms, XBRL enables a logical and consistent approach to data modelling to be taken, so that where the same piece of information appears on multiple templates, it is modelled the same way and need only be reported once.
In many cases, it is important for the collector of the report to be able to determine which reporting templates the filer intended to complete. This may be used to trigger validation, to filter the set of templates that are rendered, or to determine if the filer has met their filing obligation. A single XBRL fact may participate in multiple templates, which means that it is not possible to reliably determine which templates the filer has intended to complete by simple inspection of the reported data.
Filing indicators are a mechanism used by a number of XBRL implementations to enable filers to explicitly state which reporting templates they have completed.
The syntax currently used by these projects uses constructs that are not compatible with the XBRL Open Information Model. This document defines requirements for a representation of XBRL "filing indicators" that is compatible with the assumptions of the Open Information Model.
Filing indicators are currently modelled using tuples and make use of a custom attribute (i.e. one not defined in an XBRL specification). The Open Information Model [OIM] does not support custom attributes, and the use of tuples is increasingly discouraged for new projects. These issues with filing indicators are the only technical barrier to the use of the OIM, and its related CSV and JSON-based representations, for the large quantities of data that are collected by the projects using this approach.
This document defines the requirements for an alternative syntax for filing indicators that is compatible with the OIM, and accompanying transformations that allow conversion to and from the current syntax and the proposed new syntax.
The solution is the specification or other artefacts developed to satisfy the requirements described in this document.
An implementer is a regulator or other collector of XBRL reports that contain filing indicators prepared according to the solution.
A filer is an entity that creates an XBRL report that is required to contain filing indicators prepared according to the solution.
The current approach to filing indicators uses a tuple element ( <fIndicators> ) containing a single, repeating element ( <filingIndicator> ), the content of which is the identifier of a template. The element has an optional, boolean attribute ( @filed) that enables filers to explicitly state that a template has not been filed. If this attribute is omitted, or included with a true value, it is a statement that the template has been included.
The example below asserts that templates C_00.01 and C_01.00 have been reported, and that C_02.00 has not.
In current implementations, the codes used to identify templates correspond to labels with a specified role attached to table linkbase tables.
The solution must allow filers to include a list of templates, and make a positive or negative assertion that the template has been included in the report.
The solution must validate that only a single assertion is made about a given template.
The solution should not assume any relationship between a "template" and components in the DTS (such as Table Linkbase tables). Implementers should be free to define the mechanism by which the list of allowed templates is defined. It should be possible for implementers to prescribe validation of the list of allowed templates.
The solution must only make use of XBRL syntax that is supported under the assumptions listed in the OIM specification [OIM].
The impact on existing systems of adopting the new syntax must be minimised. For example, the solution should not require that existing taxonomies be modified in order to support adoption.
The solution must define a bi-directional mapping between the current filing indicator syntax and the proposed new syntax. Ideally, the solution should include implementations of the transformation using a suitable standard, platform-neutral technology (e.g. XBRL Formula, XSLT).
The solution does not need to support the use of multiple <find:fIndicators> tuples within a single report. If a report contains multiple <find:fIndicators> it should be considered equivalent to a single tuple containing the contents of both.
The solution should be straightforwardly extensible to include additional information about reported (or unreported) templates using OIM-compatible syntax.
The solution should provide validation to ensure that where the new syntax is used, filing indicators are not also reported using the current syntax.
The solution should define custom XBRL Formula functions that perform the following functions:
These functions should be able to process both the current syntax and the proposed new syntax, so that formula assertions can be written in a syntax-independent manner.
Ideally, the solution should include XPath implementations of the custom functions.
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 (www.xbrl.org/legal).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 (www.xbrl.org/legal).
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 Specification Maintenance Working Group (SWG) up to and including 11 October 2017. 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.