Table of Contents

1 Introduction

Filing rules specify technical constraints on reports submitted to a filing system. These are distinct from business validation rules, which enforce requirements from the underlying business domain. Whilst some filing rules are necessary in order to ensure correct and reliable operation of the filing system, XBRL best practice recommends minimising their use as they create a burden for software developers and preparers, and can create interoperability issues. This guidance provides a checklist which may be used to define filing rules for taxonomy extension by preparers. The rules in the checklist generally focus on syntactical and technical aspects of extension taxonomy. This guidance is targeted towards XBRL and iXBRL report collectors who allow preparers to extend their base taxonomy. Filing rules to constrain taxonomy extension are required to ensure:

• unsupported technical features are not used;
• preparers do not make inappropriate modifications to base taxonomy components;
• data quality errors are reduced; and
• taxonomy extensions are created consistently across filers.

This checklist is intended to be used as a reference when defining filing rules for an XBRL reporting programme. The filing rules discussed in this document are provided as guidance only; data collectors should consider whether each rule is necessary and applicable to their reporting system. A separate piece of guidance discusses the broad principles for creation and publication of filing rules and there is also a checklist for XBRL report filing rules.

2 Scope

This guidance assumes that the data collector has made the decision to allow extension taxonomies. The task force studied the EDGAR Filer Manual (US SEC) and the draft European Single Electronic Format (ESEF) Reporting Manual. The task force seeks comments on other filing manuals for taxonomy extension, which can be analysed to improve this guidance.

3 Filing Rules

This section describes filing rules for different categories, such as those related to naming taxonomy components, constraints on extended elements, relationships in the extension taxonomy and construction of the extension taxonomy.

3.1 Naming of taxonomy components

Filing rules may specify formats to be applied when naming extension taxonomy components to ensure consistency across preparers. Such naming conventions need to satisfy constraints imposed by the specification.

3.1.1 Namespaces, arcroles and roles

The namespaces for an extension taxonomy schema usually follow a pattern that identifies the entity and version or reporting period. Extended arcroles and link roles typically adopt a similar pattern to the namespace, suffixed with an identifier for the arcrole or link role. Filing rules may specify naming conventions for these components which typically require the inclusion of a version date or number, and a unique identifier for the preparer such as a domain name or stock exchange symbol. The following is an example of a namespace and link role in an extension taxonomy prepared by 'Nokia Corp' for its 'Annual and transition report' submission to the US-SEC.

• Namespace - http://www.nokia.com/20181231
• Role - http://www.nokia.com/role/StatementConsolidatedIncomeStatement

3.1.2 Element Name

Having a consistent format for element names across the base and extension taxonomies is helpful when creating an analysis model, or tagging or reviewing an XBRL report. Filing rules may specify that extension taxonomy elements should follow a prescribed naming convention, such as deriving element names from the standard label using the LC3 convention ¹. For taxonomies with labels in more than one language, filing rules should specify which language the element should be based on. Where languages use accented or other non-ASCII characters² , filing rules should specify how these are to be represented.

3.1.3 Labels

Data collectors may specify filing rules for label construction, such as requiring standard labels to be unique or restricting the use of of "period start" and "period end" labels to numeric concepts. Refer to [labels section][sec-label] of this document for other filing rules related to labels in an extension taxonomy. Data collectors may also specify general principles or style guides for standard label creation, such as requiring standard labels to be concise, requiring labels to accurately describe the meaning of concepts, and specifying where acronyms may be used in labels. Label definition often involves the use of judgement and knowledge of the business context of the elements making automated validation of the guidance impossible. Data collectors can refer to the guidance on Standard Labels when specifying such guidelines.

3.1.4 Dimensional Components

To ensure consistency filing rules may specify that dimensional components defined in extension taxonomy must follow the naming convention used in the base taxonomy. For example, the base taxonomy may use suffixes such as 'Table', 'Axis' or 'Member' for the different types of dimensional component and the extension taxonomy may be required to use the same pattern. Technically there is no requirement to constrain names of dimensional components to follow such pattern as software tools should differentiate these components adequately through the user interface.

3.2 Types of elements to be extended

This section explains the filing rule constraints for each category of taxonomy element.

3.2.1 Domain Members

Filing rules should specify whether new domain members can be added to explicit taxonomy-defined dimensions, and if so, if there are any restrictions on which dimensions can be extended in this way. For example, a dimension such as 'Consolidated and separate financial statements [axis]' can only have the members (Consolidated and Separate) defined in the base taxonomy. Filing rules should specify if there are any dimensions that will always require preparers to extend its members, as the base taxonomy does not define any usable members. For example, the base taxonomy might provide a standard "related parties" dimension, but require the filer to provide all members as these will be entity-specific.

3.2.2 Dimensions

Filing rules should specify if defining new explicit or typed taxonomy-defined dimensions is permitted, and if so, provide guidance explaining where such extensions should be used. For example, there may be specific concepts for which it is acceptable to introduce new dimensions.

3.2.3 Hypercubes

Extension taxonomies should follow the convention used in the base taxonomy for the definition of hypercube elements. Specifically, filing rules should state whether a single element should be used to define all hypercubes or if a separate element is required for each hypercube. When filing rules require multiple elements to be used, it should specify if re-use of base taxonomy hypercube elements is permitted or if new elements are required to be defined by the preparer. Data collectors should provide guidance on the extended link roles to be used when for the relationships used to define hypercubes. The different technical approaches to defining hypercubes in an XBRL taxonomy are described in the Dimensions FAQ guidance document.

3.2.4 Types of concepts

Filing rules should specify the types of concepts that can be defined in an extension taxonomy. This is typically done using a positive list specifying the permitted data types to be used for extension taxonomy concepts or a negative list forbidding certain data type. For example, filing rules may specify that extension taxonomy are only allowed to create monetary concepts (monetaryItemType). Filing rules should specify if and when extension concepts should be defined as "nillable". If concepts are permitted or required to be nillable then there should be clear guidance or rules defining where nilled facts are to be used.

3.2.5 OIM constraints

XBRL's Open Information Model (OIM) provides a syntax-independent model for XBRL data, allowing reliable transformation of XBRL data into other representations such as JSON or CSV formats. In order to achieve a simplified, logical view of XBRL data, the OIM does not support all features of XBRL v2.1's XML representation ("xBRL-XML"). Data collectors are encouraged to ensure that taxonomies and reports are compatible with the features supported by the OIM. Filing rules should prohibit preparers from using unsupported OIM features such as tuples, complex typed dimension or fraction elements. The full list of constraints is defined in the xBRL-XML specification.

3.3 Custom Taxonomy components

As described in the preceding sections, extension taxonomies will typically be used to define new concepts and dimension members, and possibly other dimensional components. Filing rules should specify which other types of taxonomy components may be defined in an extension taxonomy. Other components include:

• datatypes
• substitution groups
• reference part
• label roles
• arcroles

If any such components are permitted, filing rules should specify where their use is permitted. It should be noted that the semantics of the new taxonomy components may not be understood by consumers of the taxonomy or by off-the-shelf software. Filing rules should permit preparers to define new components only if none of the predefined ones (either in the specification or registry) match the business requirement.

3.4 Taxonomy Labels and References

3.4.1 Labels

Filing rules should specify if preparers are required or permitted to replace base taxonomy labels. The line item descriptions used by the preparers in their own presentation of a report typically do not exactly match the labels defined in the base taxonomy. To address this difference, data collectors have permitted or required preparers to replace base taxonomy labels with the labels they have used in their report presentation. In an iXBRL reporting environment, the preparer's-presentation is provided in HTML format as part of the iXBRL report, and therefore the need for preparers to provide their own labels for base taxonomy elements is greatly reduced. If data collectors wish to capture the preparer's preferred label as an XBRL label for the concept, it is recommended that this is done using a specific label role for this purpose, and is provided in addition to the base taxonomy label rather than replacing it. It is not recommended that documentation labels in the base taxonomy are replaced as they may contain important information about use of the concepts. Data collectors may also specify the label roles which can be used in the extension taxonomy. Refer to the label-roles guidance to learn more. Further constraints on labels to consider include label language; the permissible number of languages and any mandatory languages.

3.4.2 References

Filing rules should specify whether new elements defined by preparers require references, and if so which roles and parts can be used. In general, it is not recommended to overwrite references from the base taxonomy, and this should also be specified.

3.5 Extension taxonomy relationships

This section covers how to define filing rules relating to relationships between components in the extension taxonomy.

3.5.1 Relationship trees

Where extension taxonomies are required to provide taxonomy relationships such as presentation, calculations or dimensions, there are two possible approaches that can be taken. The first option is to require that relationships from the base taxonomy are included in the extension taxonomy, and then modified by the extension taxonomy. The alternative is for the base taxonomy relationships to be omitted from the extension taxonomy, and for preparers to create the required relationships from scratch. Data collectors should specify which approach is to be used. The choice of approach is likely to be determined by the nature and extent of changes to the base taxonomy relationships that the extension taxonomy is permitted or required to make. Any changes made should comply with the principles and conventions of relationships within the base taxonomy. Data collectors should clarify how presentation trees are to be designed, including the use of a single root element for each tree, header (abstract element), linkrole and preferred labels. Filing rules should include if there are any specific constraints on the calculation tree such as constraining the allowed values of the weight attribute to 1 and -1. It should also specify if any additional relationships are required to be created by the preparer. For example, the ESEF reporting manual specifies rules for creating "anchoring" relationships.

3.5.2 Dimensions network

There are a number of technical details relating to how dimensions may be constructed that should be constrained by filing rules. These include:

• Dimension containers (segment or scenario)
• Positive and Negative hypercubes
• Open and closed hypercubes
• Dimension defaults
• Validity of non-dimensional facts It is recommended that data collectors refer to the Dimension FAQ and the WGN on dimensions for more details on these issues.

3.5.3 Extensible Enumerations

When the base taxonomy uses enumeration concepts, filing rules should specify if preparers are allowed to modify the enumeration list, and, if allowed, data collectors should provide guidance on reusing the linkrole specified for enumeration concepts.

3.6 Construction of an extension taxonomy

This section concerns filing rules about how files should be present in the extension taxonomy, as well as how the extension taxonomy should be packaged.

3.6.1 Packaging

Extension taxonomies define the structure of a report rather than its content, and as such, do not necessarily need to change each time a new report is submitted. Comparability of reports is improved if there is consistency in the taxonomy used in subsequent reports. Filing rules should specify how and when extension taxonomies should be submitted to the data collector. Although extension taxonomies do not necessarily need to change between successive reports, it may make a filing system easier to manage if the extension taxonomy is always submitted alongside a report. For technical details refer to the Taxonomy Package Specification and Report Package working group note.

3.6.2 Schema and Linkbase files

Filing rules should be used to specify how linkbase files for an extension taxonomy should be constructed. In particular, this includes whether there should be a separate file for each linkbase or for link role. It is generally recommended not to mix different linkbases within a single file, for clarity. Filing rules should specify if label linkbase files are to be spilt based on language or role. Filing rules should cover whether single or multiple schema files are permitted or required, and if so, which taxonomy components should be defined in each file. For consistency, data collectors can specify a naming convention and format of files in the extension taxonomy. It is also necessary to detail how linkbase and schema files are to be referenced from the XBRL report. It is recommended that only schema files are referenced directly in the XBRL report and that linkbases are referenced via those schema files. This recommendation is in line with the OIM which does not support direct references to linkbase files from XBRL reports.

3.6.3 Base taxonomy files

Data collectors must specify which files are required to be imported from the base taxonomy files, and their URLs. Typically, these will comprise schema files where elements are defined, along with any label and reference files or any other linkbase files such as presentation or formula.

4 Guidance for Taxonomy Extension

Not all requirements specified by data collectors for taxonomy extensions can be automatically checked. The list below gives some examples of areas which typically cannot be automaticaly validation, but where data collectors may wish to provide guidance for taxonomy extensions:

• When it is necessary or acceptable to add new elements.
• What information, if any, should be included in the documentation labels for new elements.
• What style guide should be followed for creating a presentation tree such as replicating the hierarchy adopted by the preparer in their own presentation of the report.
• When to define calculation relationships.
• How unavoidable calculation inconsistencies should be handled.
• How extended link roles should be grouped for disclosures.
• The approach to changes between extension taxonomy versions. For example, not modifying element names between versions unless the meaning of the component has fundamentally changed.

5 Summary

This guidance provides a checklist of recommended XBRL filing rules for taxonomy extension. The guidance is expected to be used by data collectors defining their own filing rules. The guidance is not intended to provide a comprehensive list of filing rules as many will be dependent on the individual reporting programme. Data collectors are expected to analyse the requirements of their filing system and carefully consider whether each rule is necessary before introducing them as filing rules.