The XBRL v2.1 specification, and most subsequent modules are defined in terms of the XML syntax of component documents, and do not explicitly define the semantic information that may be represented in and inferred from XBRL documents.
This hinders the usability of XBRL data both in its native format as well as the representation of XBRL data in other formats, as there is no clear definition of how semantic information is represented or what is actually semantic information versus syntactic detail that may be ignored. In addition, the development of new specifications, most notably XBRL Dimensions, has rendered certain constructs within the original XBRL specification obsolete and effectively unused. These have never officially been deprecated, leading to an unnecessary burden to any implementer looking to implement a general purpose XBRL application.
The goal of the Open Information Model Working Group is to ensure that XBRL remains relevant in the face of changing technologies by defining XBRL semantics in a syntax-independent manner. Specifically, this means:
The initial deliverables of this effort should be:
A specification of a syntax-independent XBRL report model (“The Model”). There is no requirement for this to be presented in any particular modelling language or format, provided that the result is clear and unambiguous.
A definition of the mapping from the existing XML-based syntax for XBRL reports, and the Model.
A definition of a representation of an XBRL report that uses a non-XML-based syntax, and mappings between that syntax and the Model. It must be possible to round trip an XBRL document from the current XML format, to this alternative format, and back, with the end result being a document that is equivalent to the original according to the above model.
Possible use cases for the OIM deliverables are documented below.
A software developer may wish to develop an XBRL API that exposes a logical interface onto the data in an XBRL document. The OIM should enable as much syntactic detail as possible to be omitted from the API, and should make it possible to define an API that can be backed by alternative representations of XBRL (e.g. a database) without loss of functionality.
There have been a number of efforts to develop languages for querying or evaluating XBRL data. These have been hampered, either by exposing XBRL as XML, thereby preventing rules from being applied to non-XML-based representations (such as SQL) or by the absence of a clear information model upon which rules can be written. The existence of a defined, syntax-independent model for XBRL would form the natural basis of any new or revised XBRL rules languages.
A regulator may wish to publish data collected in XBRL documents in JSON, possibly exposed via a web services interface.
By defining the semantic information that is present and therefore must be retained for full fidelity, the Model should make it possible to define (a) a JSON format for XBRL data and (b) the mapping between XML and JSON representations of the same data. In particular, it should be possible to “round trip” report data from XML, to JSON, and back to XML, and conclude, with reference to the OIM, that the resulting XML document is semantically equivalent to the original, even if it is syntactically different.
The driver behind this use case is to make data collected in XBRL as easy to work with as possible. As such, it may be desirable to augment the report information with with information derived from the DTS, such as labels and table information, but there is no requirement to round trip this.
The OIM should define the set of semantic information that can be understood from an XBRL report.
The Model will unavoidably need to deal with technical detail as the starting point is the existing XBRL specifications which define XBRL in terms of a syntax rather than a logical model. As such, the model will need to reference the technical terms used in those documents, but, insofar as possible the constructs defined by the Model should use terminology that will be meaningful to business users.
The Model must represent the implicit and explicit semantics currently captured in XBRL constructs that are in common use, and which are considered consistent with current XBRL best practice. It is not necessary for the Model to represent everything that is currently possible within XBRL’s XML syntax. It is acceptable for the OIM to omit certain XBRL features in order to achieve a clean, and portable model.
The OIM should make it possible to determine if two reports, possibly in two different syntaxes, communicate the same business information.
The primary goal of the OIM is to capture the semantics of data in an “XBRL Report”. This corresponds most directly to an XBRL instance document, however, as the interpretation of data in an instance document is very much dependent on its associated taxonomy, the Model will need to capture at least some semantics from XBRL taxonomies.
The Model must capture semantics represented in XBRL reports conforming to the following XBRL specifications, although as noted in Section 1.5.3, the model may exclude certain features from these specifications:
The Model should, wherever possible, avoid modelling information that is inherently tied to XML syntax. For example, where the XBRL specifications allow the inclusion of “arbitrary” blocks of XML, these should be omitted from the Model entirely, or a simplified subset of information should be abstracted.
| Date | Author | Details |
|---|---|---|
| 17 April 2019 | Paul Warren | First public release |