XBRL Open Information Model Requirements 1.0

Requirements Document 13 October 2021

This version
Herm Fischer, Mark V Systems <herm@markv.com>
Mark Goodhand, CoreFiling <mrg@corefiling.com>
Paul Warren, XBRL International Inc. <pdw@xbrl.org>

Table of Contents

1 Open Information Model Requirements

1.1 Overview

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.

1.2 Initial Goals

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:

1.3 Initial Deliverables

The initial deliverables of this effort should be:

1.4 Use Cases

Possible use cases for the OIM deliverables are documented below.

1.4.1 Creation of an XBRL API

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.

1.4.2 Development of syntax-independent XBRL query and rules languages

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.

1.4.3 Publication of data in JSON

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.

1.5 Requirements

1.5.1 Scope

The OIM should define the set of semantic information that can be understood from an XBRL report.

1.5.2 Audience

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.

1.5.3 Completeness

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.

1.5.4 Semantic equivalence

The OIM should make it possible to determine if two reports, possibly in two different syntaxes, communicate the same business information.

1.5.5 Applicable document types

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.

1.5.6 Specifications covered

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:

1.5.7 Omission of XML-specific data structures

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.

Appendix A Document history

Date Author Details
17 April 2019 Paul Warren First public release