XBRL 2.1

XBRL 2.1

This wiki page is for notes about the use of the XBRL 2.1 specification. We will document here things like best practices, ideas hints in order to properly use XBRL 2.1

The HTML version of the XBRL 2.1 specification is here http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm

Marvellous things about XBRL 2.1

This section describes functionality that is included in the XBRL 2.1 specification and really facilitates the modelling of business concepts into XBRL 2.1 concepts

Tuples

Tuples groups things together. This is the main purpose of a tuple in the XBRL 2.1 specification and also in the XML Schema specification from the W3C. A Tuple represent the construction of a concept that requires other concepts in order to make it meaningful.

The tipical example of a tuple is a person. In our example, a person is composed by a name and a surname. So it is very clear and simple to understand that a person can be defined as a group of a name and a surname.

Dimensions

Dimensions was created by Ignacio Hernández-Ros (founder of Reporting Standard S.L.) in order to fill a gaap in the deifinition of concept properties and validation rules of concept properties.

A concept property is, for example, the type of a telephone number (fax, voice, ...). Properties can be defined using special XBRL Concept definitions called dimensions and possible dimension values can also be defined using XBRL and XML syntactical artifacts like hypercubes, members etc.

A property adds two things to a concept definition:

• The existence of the property for that concept
• A property value for a fact item of that concept in a report

Common errors about tuples and dimensions

Some taxonomies worldwide (and regulators) are trying to force the use of just one of the technologies (dimensions) against the other (tuples). In our experience this is just because of the personality of the decision makers and the lack of technical knowledge (of the decision makers) in order to make proper decisions. The decisions has come into a very complex modelling scenario in which companies has to create dimensions and taxonomy extensions for things that naturally are beter modelled using a tuple.

In our experience, a taxonomy can use both, Tuples and Dimensions together, in order to achieve the better quality in modelling techniques around XBRL. Some taxonomies like Australia SBR are already following this modelling technique and more will follow in the future.

All Reporting Standard XBRL products are open to use ALL possibilities that exist in the XBRL 2.1 specifications. Tuples and Dimensions because we believe the current situation in the USA (only dimensions) is not a sustainable model for the future as the rest of the world is not following them and the XBRL specifications are more open in their functionality.

Horrible mistakes

In this section we will document real bad practices that, unfortunatelly, are also real practices.

Replacing officially published taxonomy files

This is, for sure, one of the most horrible things an XBRL user can ever imagine. A regulator is changing the validation rules whenever he likes, without any notice, any information, any documentation and any possibility for the users to catch-up the changes. But it is true in the case of some regulators this is how they work... They update their taxonomy files without telling anything to anybody, without changing the official namespaces and without changing the official document locations... Reporting Standard is not going to tell you who is doing this we are going to limit ourselves to document the implications of this decisions:

• No validation is possible anylonger. An instance document that WAS valid against a previous version of the taxonomy MAY NOT be valid against a new version of the taxonomy.
• Taxonomy validation rules lose trustability. An instance document that WAS invalid against a previous version of the taxonomy MAY be valid against a new version of the taxonomy.
• The regulator cannot demonstrate it is performing well. Because a document that cannot be validated at any moment in time does not guarantee it was valid at the submission time by the regulated entity either.
• Unauditability of the changes. Because the regulator insist on not changing the official taxonomy URLs and the namespaces used in the taxonomies, the changes in the taxonomies are not auditable and not trackable by computers or humans. The process is completely out of control.
• The worst thing a regulator can do today is become less transparent. In fact, this is adding stoppers to the process building the history of the reporting suply chain and it is suspicious that some regulators are doing this things these days. (Not transparent regulators)

Navigate

Main Page