The background of Architecture Rules
A taxonomy is expressed as a syntax or a programming language. For SBR, the Dutch government selected XBRL as the language in which the financial reports and justification reports will be exchanged. XBRL offers a standardised syntax (structure) in which the reports and data are exchanged. The XBRL standard is compiled using other specifications such as the XML Schema Specification 1.0, the XLink 1.0 and XPointer 1.0 standards (6), all from the W3C. Using XML Schemas, the elements are defined that map reporters to their own data elements. The files that use XLink are called linkbases. In the linkbases (among others) relationships are expressed between the data elements with semantic meanings. For example: the data elements A, B and C are presented in the taxonomy as:
A meaning cannot be given to relationships between elements using the XML Schema standard. Intrinsic to the choice of XML Schema is that there is a large degree of flexibility. For parties wishing to formulate reports with a closed format (such as a tax declaration), this flexibility is not always needed because misunderstandings can arise about the exact meaning of the information submitted. Flexibility is restricted by laying down rules regarding the use of XBRL in this architecture document.
The XSD specification states that names of directories and file names simply help to create groups in the schema (in this case the Dutch Taxonomy). They then serve more as visual identification, opposed to in relation to the technique of importing the content of the files that they use. XSD uses namespaces to categorise the content of schema files, a string of characters that uniquely identify a group of 'things' between the <> characters. In the XSD standard, the ‘things’ are called 'nodes'.
- Rule: Each schema file HAS to have one namespace: the target namespace.
In theory, it is possible to specify not to work with a target namespace, but this is not allowed.
In the taxonomy the element nodes are extremely important. These are the carriers of the facts that are communicated. The element nodes have to have a unique name within a namespace. An element with a name attribute (@name) is called an element with local name. The local name, along with the namespace, form an element that is unique in the XML schema namespace. To contact an element from a namespace other than in the schema in question, that namespace and the local name can be referenced. The combination namespace and local name is called a Qualified name or QName. In this combination of namespace and @name, the namespace is abbreviated by a short string: the namespace prefix.
Element nodes can also be given an attribute named ID (@ID). This allows an element to be addressed from XML files other than schemas. This is done using the XPointer standard. Because XBRL commonly uses XLink files (linkbases), an @ID on elements is needed to be able to reference an element from a linkbase.No @ID on the element means that this cannot be addressed by XLink, meaning no relationships can be created with other (meta)data, such as for example labels. It should be borne in mind that @ID has to be unique within a namespace. When using several namespaces, duplication can therefore occur. Using naming conventions, the Dutch Taxonomy Architecture lays down rules to prevent this from happening in the Dutch Taxonomy.
The XLink standard enables data elements to express relationships and to assign values to those relationships. Relationships can also be created within XSD between elements, but no additional values to that relationship itself. A linkbase is a collection of linkages between XML nodes. Those XML nodes are often but not always elements. Every linkbase is addressed from a schema by means of a <link:linkbaseRef> in which a linkrole is declared. Like a namespace, a linkrole is a string of characters that have to be unique; a linkbase can contain several linkroles. Linkroles contain (optional) references to <link:loc>, <link:arc> and <link:resource>.
- The locators work with XPointer to designate an element in a namespace.
An example of an Xpointer expression:
<link:loc xlink:type="locator" xlink:href="nl-common-data.xsd#nl-cd_DateOfBirth" xlink:label="nl-cd_DateOfBirth" />
- A resource is an XML node that is defined in the linkbase itself and can contain ‘anything’. The great advantage of a linkbase is that attributes can be introduced to a relationship, which means that this is more than ‘A is a child of B’.
An example Resource:
<link:reference xlink:type="resource" xlink:role=http://www.xbrl.org/2003/role/reference xlink:label="wetLB1964"> <ref:Name>Wet LB1964</ref:Name> </link:reference>
- The arcs map either locators, or locators and resources or resources to one another.
Example Locator – locator linkage:
<link:loc xlink:type="locator" xlink:href="nl-common-data.xsd#nl-cd_DutchAddress" xlink:label="nl-cd_DutchAddress"/> <link:loc xlink:type="locator" xlink:href="nl-common-data.xsd#nl-cd_PostalCodeNL" xlink:label="nl-cd_PostalCodeNL"/> <link:presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" use="optional" order="5.0" xlink:from="nl-cd_DutchAddress" xlink:to="nl-cd_PostalCodeNL"/>
Example Locator - resource linkage:
<link:loc xlink:type="locator" xlink:href="nl-common-data.xsd#nl-cd_CountryCodeISO" xlink:label="nl-cd_CountryCodeISO"/> <link:reference xlink:type="resource" xlink:role=http://www.xbrl.org/2003/role/reference xlink:label="wetLB1964"> <ref:Name>Wet LB1964</ref:Name> </link:reference> <link:referenceArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/concept-reference" order="1.0" xlink:from="nl-cd_CountryCodeISO" xlink:to="wetLB1964"/>
Example Resource – resource linkage:
<test:element xlink:type="resource" xlink:label="label_a">Thing a. </test:element> <test:element xlink:type="resource" xlink:label="label_b">Thing b. </test:element> <gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/2008/generic-label" order="1" xlink:from="label_a" xlink:to="label_b"/>
The XBRL standard comprises various modules that can be optionally applied. Not all of the modules listed below form part of the SBR implementation. The decision in respect of whether and how a module will be applied forms part of the SBR policy concerning all parties.
- XBRL 2.1 is a standard that uses the aforementioned XML standards and places constraints on these. Those constraints are sometimes enforced by a schema, but often also simply by the specification (Word document). Plenty of software is available on the market that can automatically enforce the constraints. In addition to the 2.1 specification, XBRL has a number of additional modules. Those modules add options for data modelling in the taxonomy. Not all modules are used or allowed by the Dutch Taxonomy Architecture, but a summary is provided for the sake of completeness.
- XBRL Dimensional Taxonomies (XDT 1.0) is the XBRL module that enables multidimensional modelling. Instead of an element with attributes which are each given a value, an element can be included in a dimensional structure where it is held as domains. The reporter who wishes to use an element will be able to add more information to the context of that element, information concerning the dimension and the domain that apply. Known examples are the region dimension and the product dimension
- XBRL Generic Links (1.0) is the XBRL module that, in addition to linkbases for specific purposes (such as presentation and labels) allows linkbases to be defined everywhere and which permits linkages to all nodes, provided that these can be addressed. The XBRL basic specification only allows linkages to elements and resources. XBRL Generic Links broadens these options.
- XBRL Formula (1.0) is the XBRL module for laying down business rules in a structured and feasible format. An XSD enforces a number of verifications for each element, such as the datatype and the number of permitted repetitions. Verifications across elements are not possible using the XSD standard. An example of this type of verification is: if there is A B has to be > 1. These expressions are possible with the Formula specification.
- XBRL Versioning Specification (XVS, Candidate Recommendation) is the XBRL module that allows the differences between two taxonomies to be communicated in a structured manner and to explain why amendments have been made. This can be used to give software the ability to automatically process certain amendments on mapping tables or instances made for taxonomy 1 can be converted to taxonomy 2.
- Inline XBRL (1.0) is the XBRL module which enables an XBRL instance to be merged with HTML code. This gives the sender the option to supply the data (XBRL) in a structured manner and to include a presentation form on which the sender will see that this data has to be ‘seen’ by the recipient.