Dutch Taxonomy Modularity

From Logius SBR EN Wiki
Jump to: navigation, search

Components

The Dutch Taxonomy uses two parameters that are used to formulate the modularity: directories and files and XBRL grouping systems such as Tuples, Linkroles, Hypercubes, Domains etc.


Directories

The subdivision of XBRL parts between directories is based on the role of the content classified into participating parties, functional use and technical content.

  • The participating parties are given a (short) name that is shown in the names of the folder directly under the root folder. The content of that file is solely assignable to that party.
  • The releasemoments are reflected in a folder ,marked with the date of release.
  • The functional use of folders in a release is reflected in functional names that can be identified by the parties that have to create instances.


The names of the directories and files are defined in the Overview of naming guidelines. This comprises four levels:


A


1. The first level (the root) is the DTA-version that applies to the Dutch Taxonomy.

2. The second level are the NT parties. This allows a party that supports only one report to trace all the required XBRL components in one step.

3. The third level is the classification in releases by date. Content can refer to XBRL components in other folders about other release dates (but only within the same version NTA). As a result, the parties can release independently of each other, and reports will be possible in which the content (concepts) will change less than once a year;

4. The fourth level has a functional driven format. The layout of the fourth level of the NT is as follows:

  • In the dictionary folder, things are included that focus on the definition of terms, like data dictionaries and structured semantic relationships between those concepts. These include:
    • Schema(s) of concepts and corresponding label and reference linkbase(s) with non-abstract items;
    • Linkroles that group relationships into the arc roles ‘general-special’, ‘essence-alias’, ‘similar-tuple’;
    • Linkbases that establish relationships between non-abstract items that are also defined for those die items, e.g. Homonyms and Synonyms. These relationships are the product of the harmonisation process and can only be created by SBR management;
    • Schema(s) and corresponding label and reference linkbase(s) with non-abstract tuples;
    • Schema(s) with custom data types and enumerations and the corresponding generic linkbases;
    • schema(s) and corresponding generic linkbase(s) containing elements required as an extension of XBRL 2.1. For example link:part for reference resources, and new arc roles. For very stable extensions (used across several Dutch Taxonomy versions) it MAY be decided that these will no long be supplied with every Dutch Taxonomy version, but to give them a specific location, such as an Internet location. For some components such as arc roles, roles and types, a register is maintained by XBRL International. If possible and relevant, SBR extensions are registered here and therefore supported through XII and no longer in the Dutch Taxonomy version;
    • Schema(s) and corresponding label, reference and definition linkbase(s) containing abstract items that are applied as a dimension in one or more cubes (tables);
    • Schema(s) and corresponding label, reference and definition linkbase(s) containing abstract items that are used as a domain and domain members in one or more dimensions;
    • Schema(s) and corresponding label, reference and definition linkbase(s) containing abstract items that are used as dimension and hypercube on one or more non-abstract items;
  • The presentation folder contains all linkbases (presentation link bases and table linkbases) and schemes (presentation and table items) that focus completely on presenting data. These include:
    • Schema(s) and corresponding label and presentation linkbase(s) containing abstract items that serve to show the presentation;
    • (report) Linkroles, the purpose of which is to support the presentation and which are expressed as parent-child arc roles;
    • Schema(s) and corresponding labellinkbases for tables;
    • Linkroles the purpose of which is to define tables.
  • In the validation map things are included that focus on validating data in an instance document, such as dimensional linkbases and formula linkbases. These include:
    • (domain) Linkroles, the purpose of which is to enable validations and which are expressed using arc roles as, ‘domain member’, ‘requires element’, ‘dimension domain’, ’hypercube dimension’ and ‘all’;
    • Schema(s) and corresponding generic linkbase(s) containing elements that are required to make business rules in the form of XBRL Formulas, to be enforceable;
  • Entry points include schema(s) that are the entry to reports. This is the schema that is referred to in the instance. The schema is given a name that is identifiable by the market, in which a reminder is given for the obligation to provide a report.


XBRL Groups

The XBRL 2.1 specification has various mechanisms by means of which groups can be created in the taxonomy. For reuse, it is extremely important that the entire DTS is divided into sufficiently small and significant groups. This simplifies things for the re-users and extension creators. It is also possible to go too far when breaking down data that has been gathered. Ultimately, the concepts that are reported on are the lowest level. A separate schema should not be created for every concept; these should only be imported if the concept also has to appear in a report.


The XBRL group components are:* Namespaces This is a group of concepts according to a namespace. A namespace is the same as a schema (file). In theory, a namespace can be divided across several files but the use of xs:include, by means of which the files are strung together, is not allowed in the Dutch Taxonomy Architecture. No functional meaning has been laid down by XBRL in terms of dividing concepts across namespaces. That means that DTS authors can assign a meaning to this themselves (e.g. turnover tax or income tax concepts).

  • Tuples This is a group of concepts according to a complexType. The functional meaning of this is that the concepts derive a meaning from one another and are inseparable from one another (for example, street and house number). Another reason for grouping may be that limited repetition has to be possible of the (group of) elements.
  • Linkroles This is a group of relationships. Relationships can be expressed between concepts but also between a concept and 'other' information such as a label or a definition. The functional meaning in dividing relationships across linkroles only means the type of linkrole (such as: label, reference, presentation, etc.). But within a type, no functional meaning is assigned and the DTS author can assign a meaning to this himself (for example shareholders, shipping, balance sheet).
  • Linkbases This is a group of linkroles. Technically, these can be all types of linkroles, but the Dutch Taxonomy Architecture dictates that there may only be one type. In fact, if there are other technical indicators, it would be mandatory for the linkroles to also be divided into different linkbases. This would mean that the labels would be divided into both the resource role and the language and domains, dimensions and hypercubes to the arc role. Within these technical requirements, the DTS author is free to choose a functional division.
  • 'Domains A domain is a group of domain members. Domain and domain member are abstract items. A domain can represent a functional grouping, for example, all countries in the world, but also a (validation) technical grouping, for example all countries with which VAT can be offset. Domain members can be grouped into several domains. Each domain has its own linkrole; these can be addressed from an axis (dimension).

An unusual domain is that of the primary items. These are grouped into a special abstract item that is defined by SBR (because it is not defined by XII), the primary Domain Item. Aside from the use on primaries, otherwise the same rules apply than in the other domains.

  • Axes (Dimensions) An axis (dimension) CAN be formulated from domain(s), but domain members can also be linked directly. A dimension is an abstract item and is always a (validation) technical grouping of domains and domain members. Domains and domain members can be grouped into several axes (dimensions). Each axis (dimension) has at least one linkrole, so that this can be addressed from a table (hypercube).
  • Tables (Hypercubes) A table (hypercube) is formulated from axes (dimensions). One of the axes HAS to be formed by the primaries directly or by means of the primary DomainItem. Any other axes are always the axes (dimensions) that reference the abstract domain members. Only a technical hypercube (table) is needed because the validation meaning in the relationships are hidden and not in the table itself. A hypercube (table) has at least one linkrole.


Important: Axes (dimensions) and Tables (hypercubes) are redefined in various linkroles!! Listed below is the maximum and minimum set of components in a Dutch Taxonomy.


A






A


Green = XML Schema file
Yellow = XLink linkbase file
Red = does not exist yet