Dutch Taxonomy Extensions

From Logius SBR EN Wiki
Jump to: navigation, search

Dutch Taxonomy extension methods

To create a Dutch Taxonomy (domain) extension ('extend') there are various options. Not all options available through XBRL are permitted within the Dutch Taxonomy. The following extension methods can be adopted within the XBRL standard:

  • Create your own schema and import the required parts of the DTS;
  • Create your own schema and stipulate that, in the instance, the DTS and your own schema have to be retrieved;
  • Create your own linkbase that switches off the DTS relationships that are not needed (@use=’prohibited’) and potentially adds new relationships. This is only possible if all concepts already exist. Retrieve this linkbase in the instance.

Difference between Dutch Taxonomy parties

When creating a domain extension, there is a difference between the Dutch Taxonomy and the non-Dutch Taxonomy partner ('Dutch Taxonomy extender'). The Dutch Taxonomy partner conforms fully to the rules that apply to the Dutch Taxonomy and the Dutch Taxonomy Architecture as laid down in this Dutch Taxonomy Architecture wiki. The Dutch Taxonomy partner is able to join in conversations about the rules in the SBR programme.
The non-Dutch Taxonomy partner creates an extension on the Dutch Taxonomy without conforming to Dutch Taxonomy and Dutch Taxonomy Architecture rules. The extensions of Dutch Taxonomy partners and Dutch Taxonomy extender differ as follows:

  • The Dutch Taxonomy extender does not have a code for the organisation or domain issued by SBR;
  • The Dutch Taxonomy extender is unable to fall back on the expertise of SBR Management;
  • The Dutch Taxonomy extender does not have to reuse terms. The Dutch Taxonomy extender can determine which elements will be included in the extension;
  • The Dutch Taxonomy extender does not have to supply a mandatory set of documentation, such as a Business Rules document, examples or versioning information;
  • The Dutch Taxonomy extender is not part of the SBR publication process with fixed milestones and schedule;
  • The Dutch Taxonomy Architecture validation (by the administrator) is optional;
  • The Dutch Taxonomy extender has limited access to SBR consultative bodies.

Dutch Taxonomy partner extensions

Additional rules apply to Dutch Taxonomy partners. The Dutch Taxonomy is built up in modules around three key concepts: owners of data, releases and technical use of the data. Dutch Taxonomy partners are expected to create their own (domain) taxonomy, which fully complies with the requirements of the Dutch Taxonomy Architecture and the requirements described in this wiki. In terms of the taxonomy, this means that only concepts and XML elements can be used that are released by the SBR community to the joint Dutch Taxonomy partners and the NL-GEN and NL-CD (basic) taxonomies. These taxonomies can be found in the SBR/-dictionary folder and can be used by the SBR partners in their own taxonomy, within the NTA version, without consultation.

Every Dutch Taxonomy partner is given a domain code which distinguishes them from the other Dutch Taxonomy partners. This code is used as a directory name on the first level. The code is assigned by the Dutch Taxonomy administrator. In the Dutch Taxonomy partner's own directories, directories are created for releases. In each of the release directories the Dutch Taxonomy Architecture stipulates the maximum set of technical subdirectories (see Modularity). Each Dutch Taxonomy partner can place its schemas and linkbases in these subdirectories. After the partner has created its own taxonomy, this is submitted to the administrator of the Dutch Taxonomy, who performs quality screening to make sure that all requirements have been met. The administrator of the Dutch Taxonomy is responsible for publishing the Dutch Taxonomy.

Dutch Taxonomy partners can use the elements of the other Dutch Taxonomy partners within an NTA version. The condition attached to this is that a linkbase is supplied, which describes which elements, from which partners, are used. These can be determined automatically and the result MAY NOT be hard linked within the partner's own DTS. The relationships of the reused elements are therefore recorded in a separate linkbase. This is useful in terms of giving third parties access to concepts that are reused and to quickly list any consequences of changes to concepts.

Creation of a new domain extension

The Dutch Taxonomy partner will take the following steps to create a new domain extension:

  1. First and foremost: consult with the administrator of the Dutch Taxonomy Management team. By opting for a Dutch Taxonomy partner, you commit to the (technical) Dutch Taxonomy requirements and the SBR publication process. The administrator can provide a clarification in this respect. The new Dutch Taxonomy partner will be given a code that is used to place your files in the various directories.
  2. First of all, gain knowledge about XBRL, Dutch Taxonomy and Dutch Taxonomy Architecture or work with a party that has this knowledge. The objective is to create an XBRL taxonomy that is built up in line with the Dutch Taxonomy Architecture rules.
  3. Participate in discussions within the Data Expert Group. During these discussions, the technical and substantive frameworks of the Dutch Taxonomy are discussed and determined with the market parties. In addition, the Dutch Taxonomy partners have a separate Dutch Taxonomy workgroup meeting.
  4. List all terms that form part of your own request, with an exact definition. The terms (or concepts) are included as elements in the taxonomy. The definition can be laid down in a text (using a documentation label in the taxonomy) or by a reference to where the definition can be found: a URL or a document name with chapters, etc. (by a reference link in the taxonomy).
  5. The terms have to be compared to the pre-existing terms in the Dutch Taxonomy, to find out which terms already form part of the Dutch Taxonomy and which are missing. When doing so, pay attention to any modelling differences. What you see as a separate concept may have been used to formulate an enumeration or dimension. When you find third party concepts that you can re-use, these are removed from your list. Only the missing terms are included in a Dutch Taxonomy domain extension.
  6. Establish the data types and code lists that are required. Note that, in the Dutch Taxonomy, re-use is important. If you impose constraints by means of a datatype, this reduces the possibility of re-use by other Dutch Taxonomy partners.
  7. Translate the new terms into English (UK spelling) and establish the attributes required for XBRL of each of the terms. The English name forms the basis of the element name. The Dutch name comes back as the Dutch label of the element.
  8. Establish the data modelling of each of the elements: do tuples have to be used (for repetition or grouping) or dimensions (for validation tables).
  9. Establish the headings, hierarchy and subhierarchy that you will need in order to formulate the presentation of your elements. This concerns the nesting of the elements under these headings and the order of the elements if they fall under a similar heading.
  10. Establish the entry points that you wish to use. These are names of reports created by you, recognised by the market. Each entry point refers to at least one presentation linkbase that picks up the required concepts.
  11. Establish the business rules to be followed in relation to the reported facts. You can include these business rules as text in your user manual or Business Rules document, or as syntax in an XBRL Formula linkbase.
  12. The domain taxonomy can now be put together. This taxonomy can be validated by the administrator of the Dutch Taxonomy based on the rules of the Dutch Taxonomy Architecture. Using standard XBRL taxonomy tooling, it can be established whether the taxonomy meets the XBRL standard.
  13. Prepare a Business Rules document with rules that the reporter (in the instance) has to adhere to, but that are not included in the taxonomy because the standard does not provide for this. Even if you use certain XBRL functionality, such as preferredLabels you have to include rules relating to the use of this in the Business Rules. The Dutch Taxonomy Architecture specifically describes which XBRL functionality qualifies for this.
  14. Create sample instances to test your taxonomy for correct operation. An XBRL and Dutch Taxonomy Architecture valid taxonomy can still not yield correct results. Tests using instances is the best way of determining this.
  15. If you are confident in your taxonomy and you have a working receipt application, you can send an Alpha version through the administrator of the Dutch Taxonomy to the market. These can be selected parties. You would inform these parties of this beforehand.
  16. The changes proposed by the market may result in a new taxonomy. Each version has to be assessed by the administrator of the Dutch Taxonomy before this is made available to the market.
  17. At a predetermined and communicated date the Beta version of the Dutch Taxonomy will be published, which consists of the basic part or the (domain) extension taxonomy of the Dutch Taxonomy Partner. For the schedule and milestones, see Planning and Control (Dutch).
  18. At a predetermined and communicated date the final version is adopted and published.
  19. You are obliged to send versioning information with each subsequent version of your taxonomy. Obviously that is not required for the first version, but this is required for each subsequent version.