Open Information Model 1.0

Candidate Recommendation 12 June 2019

Copyright © XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/oim/CR-2019-06-12/oim-CR-2019-06-12.html>
Editors:
Paul Warren, XBRL International Inc. <pdw@xbrl.org>
Herm Fischer, Mark V Systems Limited <fischer@markv.com>
Mark Goodhand, CoreFiling <mrg@corefiling.com>
Contributor:
Daniel Dracott, CoreFiling <djd@corefiling.com>

Status

Circulation of this Candidate Recommendation is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to oim@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document describes a syntax-independent model for business reports that conform to the XBRL v2.1 and XBRL Dimensions v1.0 specifications. The model is intended to enable easy and lossless transformation of a well defined set of semantics between a variety of different syntactic representations, including the XML syntax defined in the above specifications.

Comment

1 Paul Warren:It should be noted that the model does not capture the resource role for footnote resources. The working group is actively seeking feedback on this point. It is currently felt that the combination of extended link role ("footnote group") and arcrole ("footnote type") provide adequate scope for customisation and classification of footnotes, and that an additional property is unnecessarily complex and confusing outside of the XML syntax (and thus in the absence of XLink).

Table of Contents

1 Introduction
1.1 Scope
1.2 Terminology
1.3 Namespaces and namespace prefixes
2 Processors
3 XBRL Report Model
3.1 Datatypes
3.2 Reports
3.3 Facts
3.4 Schema document references
3.5 Dimensions
3.6 Links
3.6.1 Footnotes
3.6.1.1 The xbrl:note concept
4 Equality and equivalence
4.1 Equality definitions
4.2 Equivalence definitions

Appendices

A References
B Intellectual property status (non-normative)
C Document History (non-normative)
D Errata Corrections incorporated in this document

Table

1 Namespaces and namespace prefixes

Definitions

Concept Core Dimension (Component)
Conformant processor
Core Dimension
Dimension
Entity Core Dimension (Component)
Enumeration fact
Equal dimension value
Equal fact property
Equal facts
Equal reports
Equivalent fact property
Equivalent facts
Equivalent reports
Fact (Component)
Fact datatype
Language Core Dimension (Component)
Link group (Component)
Note ID core dimension (Component)
Numeric fact
Period Core Dimension (Component)
Report (Component)
Schema document reference (Component)
SQName fact
Supported specification
Taxonomy-defined Dimension (Component)
Text fact
Unit Core Dimension (Component)
Validating conformant processor
XHTML fragment

Error codes

xbrle:illegalNoteFactDimension
xbrle:illegalStandardFootnoteTarget
xbrle:invalidXBRL
xbrle:unusedNoteFact
xbrle:xhtmlElementInNonDefaultNamespace


1 Introduction

The XBRL v2.1 [XBRL 2.1] and XBRL Dimensions v1.0 [DIMENSIONS] specifications define an XML-based syntax for business reports, and accompanying metadata definitions known as taxonomies. It is becoming increasingly appealing to work with XBRL data in a variety of different formats such as JSON, relational and other databases and CSVs. Such use is hampered by the lack of a clear definition of the information that may be considered significant in an XBRL report, as distinct from that which is syntactic detail. This leads to inconsistency in the data that is understood and how it is represented, and often to the exposure of unnecessary syntactic detail to end users.

This specification defines a syntax-independent model for an XBRL report, which allows different syntactic formats to be used to represent the same data. The model captures a subset of the information that can be represented in the XML syntax defined by XBRL v2.1, in order to provide a simple and portable model.

1.1 Scope

This document provides a model for an XBRL report (or XBRL instance) that conforms to the set of supported specifications. It does not attempt to model the metadata information defined in an XBRL taxonomy. The Working Group recognises the importance of taxonomy information when working with XBRL data, but believes that there is considerable value in a model that is restricted in scope to XBRL report on its own, and thus has chosen to address this requirement first.

Taxonomy information is expected to form the basis of future specifications that expose such information either in a separate model, or as layers of additional information that augment the model defined in this specification.

The supported specifications are:

1.2 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].

The keywords concept, context, duplicate, DTS, fact, footnote, resource, tuple and XBRL instance are to be interpreted as described in the XBRL specification [XBRL 2.1].

The keywords dimension, hypercube, typed dimension, explicit dimension and dimension default are to be interpreted as described in the XBRL Dimensions specification [DIMENSIONS].

The keywords time interval, local time and zone designator are to be interpreted as defined in ISO 8601 [ISO8601].

1.3 Namespaces and namespace prefixes

Namespace prefixes [XML Names] will be used for elements and attributes in the form ns:name where ns is the namespace prefix and name is the local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces are consistent with Table 1.

The prefix column in Table 1 is non normative. The namespace URI column is normative.

Table 1: Namespaces and namespace prefixes
Prefix Namespace URI
dtr-type http://www.xbrl.org/dtr/type/*
xbrl http://www.xbrl.org/CR/2019-06-12
xsd http://www.w3.org/2001/XMLSchema
enum2 http://xbrl.org/CR/2018-04-23/extensible-enumerations-2.0
xbrlehttp://www.xbrl.org/CR/2019-06-12/error

The prefix dtr-type denotes any namespace that is the namespace for a type defined in the Data Types Registry [DTR STRUCTURE].

2 Processors

This specification defines two classes of processors:

3 XBRL Report Model

The report model is defined as a series of components, each having a set of named properties. These components, and their associated properties are defined in the tables shown below. Components may also have constraints associated with them which all instantiations of these components must adhere to.

3.1 Datatypes

The report model uses the XML Schema datatypes system [XML Schema Datatypes] for defining the datatype of values. It does not make use of the XML Schema structures system [XML Schema Structures], as this does not make sense outside of the context of an XML document.

It should be noted that there are some references in this document to XBRL "item types", such as dtr-type:domainItemType. References to these item types are primarily to identify classes of facts, based on their datatypes.

Item types are technically XML schema complex types, as they contain definitions of allowed XML attributes. These attribute definitions are not applicable to the report model, and values in the report model are only required to comply with the "simple content" portions of these datatypes (see complex type definitions with simple content [XML Schema Structures]).

Values in the report model refer to the value within the value space. The lexical representation does not form part of the model.

For example, 1, 1.0 and 1.00 are all alternative lexical representations of the same xsd:decimal value. An OIM processor must treat all these values as equal, and is not required to retain the lexical representation from which the value was obtained.

3.2 Reports

The top-level component is a report.

Component: Report
Properties:
{taxonomy}
A list of schema document references
{facts}
An unordered collection of facts.

3.3 Facts

Component: Fact
A fact is a discrete piece of information in an XBRL Report. All facts have the following properties.
Properties:
{id}
A unique identifier for the fact. The value must be an NCName, and must be unique across all facts within the report. This property is required.
{dimensions}
A set of dimensions. The set may contain at most one of each core dimension. The set may contain multiple taxonomy defined dimensions, but their {name} properties must be unique within the set.
{links}
A set of link groups associated with the fact.
{value}
The value associated with this fact. This may be the special value "nil". The meaning of a fact reported as "nil", the distinction between this and a fact that is not reported, or a fact reported with an empty, or zero, value (where applicable) is implementation dependent.
{decimals}
The precision of the value, expressed as a number of decimal places, or "infinity", indicating that the value is infinitely precise. The decimals property is required on, and MUST only be present on, numeric facts.

A fact's datatype is the XML Schema type of the concept identified by the fact's concept core dimension.

A numeric fact is a fact with a datatype that is derived from the XML Schema type of xsd:decimal.

A text fact is a fact with a datatype that is derived from the XML Schema type of xsd:string, but which is not one of, or a type derived from one of, the following types:

  • xsd:language
  • xsd:Name
  • dtr-type:domainItemType
  • dtr-type:noLangTokenItem
  • dtr-type:noLangStringItemType

An SQName fact is a fact with a datatype that whose type is, or is derived from dtr-type:SQNameItemType.

An enumeration fact is a fact with a concept core dimension that identifies an enumeration concept. An enumeration fact has a value that is either a single expanded name or a set of expanded names.

Note that in the above definitions, "derived from" includes indirect derivation via intermediate types.

The text fact definition identifies those facts to which the language core dimension is applicable.

3.4 Schema document references

Component: Schema document reference
Properties:
{href}
A URL to an XML Schema document.

This model simplifies the mechanism for identifying a taxonomy to a list of references to XML Schema documents. The xBRL-XML syntax permits references to both schema and linkbase files, and also references in the form of links to the definition of role and arcrole types. References to linkbases are not supported, and <roleRef> and <arcroleRef> in the xBRL-XML syntax are subject to special treatment. See [xBRL-XML] for full details.

3.5 Dimensions

A dimension is a piece of additional information that serves to uniquely identify a fact. A dimension may either be one of the core dimensions listed below or a taxonomy-defined dimension.

A core dimension is a dimension that is defined by the XBRL v2.1 specification, as distinct from those which are defined in a taxonomy using the XBRL Dimensions specification [DIMENSIONS] .

Component: Concept Core Dimension
Properties:
{name}
The expanded name corresponding to xbrl:concept
{value}
An expanded name identifying an XBRL concept.
Constraints:

The concept core dimension is required on all facts.

Component: Entity Core Dimension
The entity core dimension represents the primary legal entity (person or organisation) associated with a fact.
Properties:
{name}
The expanded name corresponding to xbrl:entity
{scheme}
A URI denoting the scheme from which an identifier is drawn.
{identifier}
A string identifying the entity to which the fact relates.
Constraints:

The entity core dimension is optional, and MAY be omitted if there is no primary legal entity associated with a fact, either because the fact does not relate to a legal entity, or because the fact captures a transaction or relationship between two or more legal entities with equal standing. As defined in [xBRL-XML], a special entity with scheme of 'https://xbrl.org/entities' and identifier 'NA' is used to represent the absence of this dimension in xBRL-XML syntax.

Component: Period Core Dimension
The period core dimension represents the period of time, or instant, to which a fact is applicable. Whilst the xBRL-XML representation uses different elements to represent instants and durations, this specification uses a common model for both in the form of an time interval as defined in ISO 8601 [ISO8601], with instants being represented using a zero-length time interval.
Properties:
{name}
The expanded name corresponding to xbrl:period
{interval}
A time interval, as defined in ISO 8601. The time interval MAY be zero-length (i.e. start and end at the same instant), denoting an instant in time. The time interval MAY be defined in local time (i.e. without a time zone designator) in which case processors MUST NOT assume a particular time zone, but MUST preserve the information that the time interval is in local time.

This specification, being a syntax-independent model, does not make use of the representations defined in ISO 8601, but as ISO 8601 is the representation used in xBRL-XML and in other representations based on this specification, the model draws on the terms and definitions used in ISO 8601 in order to ensure that the {interval} property can be represented using formats defined in ISO 8601.

Constraints:

The period core dimension is optional. As defined in [xBRL-XML], the absence of the period core dimension is represented by the special value of "forever" in xBRL-XML syntax.

Component: Unit Core Dimension
Properties:
{name}
The expanded name corresponding to xbrl:unit
{numerators}
An unordered collection of expanded names, identifying individual measures.
{denominators}
An optional, unordered collection of expanded names, identifying individual measures.
Constraints:

The unit core dimension MUST only be present on numeric facts. The unit core dimension is optional on numeric facts (the xbrli:pure unit used in xBRL-XML is mapped to a fact with an absent unit core dimension [xBRL-XML]).

Component: Language Core Dimension
Properties:
{name}
The expanded name corresponding to xbrl:language
{language}
The language in which the fact is reported. Languages MUST be representable as using a valid BCP 47 [BCP47] language code.
Constraints:

The language core dimension may only be present on text facts and is optional on such facts.

Component: Note ID core dimension
The note ID core dimension is used on xbrl:note facts in order to avoid multiple occurrences of such facts in a report from being classified as duplicates.
Properties:
{name}
The expanded name corresponding to xbrl:noteId
{id}
A unique identifier for a fact.
Constraints:

The {id} property MUST be the same as the fact's {id} property.

This dimension MUST be present on all facts with a concept core dimension of xbrl:note, and MUST be absent on all other facts.

Component: Taxonomy-defined Dimension
Properties:
{name}
The expanded name identifying the dimension.
{value}
The value for the dimension. Values for taxonomy-defined dimensions do not have any associated language information.
Constraints:

Taxonomy-defined dimensions MUST only be present on facts.

Explicit dimensions will have a type of xsd:QName, but it should be noted that a type of xsd:QName does not imply that the dimension is explicit: it may be a QName typed dimension. The actual nature of the dimension can be determined from the DTS.

The set of taxonomy-defined dimensions associated with a fact does not include any explicit dimensions using a dimension default.

3.6 Links

Links represent relationships between facts in a report.

Component: Link group
A link group is a collection of relationships between facts in a report. The group is uniquely identified by the combination of the {group} and {link type} properties. The relationships in a link group have a common source fact, which is the fact on which the link group is defined. The target facts for the relationships are defined by the {target facts} property.
Properties:
{group}
A URI identifying a grouping of links between facts.
{link type}
A URI identifying the type of the relationships between the facts in the group.
{target facts}
A list of facts which are the target of the links in the group.

3.6.1 Footnotes

Links are a generalisation of the footnote mechanism defined in XBRL v2.1.

This specification defines prescribes special behaviour for the standard link type of http://www.xbrl.org/2003/arcrole/fact-footnote. The {target facts} for any link group with this {link type} MUST have a concept core dimension of xbrl:note (xbrle:illegalStandardFootnoteTarget).

The mapping between links and footnotes as defined in XBRL v2.1 is described in xBRL-XML [xBRL-XML].

[Paul Warren: It should be noted that the model does not capture the resource role for footnote resources. The working group is actively seeking feedback on this point. It is currently felt that the combination of extended link role ("footnote group") and arcrole ("footnote type") provide adequate scope for customisation and classification of footnotes, and that an additional property is unnecessarily complex and confusing outside of the XML syntax (and thus in the absence of XLink). ]

3.6.1.1 The xbrl:note concept

This specification defines the xbrl:note concept, which is used to represent text footnotes as defined in XBRL v2.1, and for which specific handling is prescribed in xBRL-XML [xBRL-XML]. As documented above, where a fact has a concept core dimension of xbrl:note it MUST have the note ID core dimension.

The value of the xbrl:note concept is a string containing a serialisation of an XHTML fragment. The serialisation assumes a default namespace of http://www.w3.org/1999/xhtml, and any elements in that namespace MUST use the default namespace. xbrle:xhtmlElementInNonDefaultNamespace.

An XHTML fragment is an XML fragment in which any top-level element nodes are in the http://www.w3.org/1999/xhtml namespace.

Any facts with a concept core dimension of xbrl:note MUST be included in the {target facts} property of at least one link group (xbrle:unusedNoteFact), and MUST NOT have any taxonomy-defined dimensions (xbrle:illegalNoteFactDimension)

4 Equality and equivalence

This specification provides separate definitions of equality and equivalence for facts and reports. Equivalent reports can be considered to convey the same semantic information. The stricter definition of equal reports additionally requires fact {id} properties to be equal. {id} attributes can be useful in providing traceability of facts through different syntactic representations, but do not form part of the semantic information provided by a report.

4.1 Equality definitions

Two reports, A and B, are equal under this model if, for every fact in A, there is an equal fact in B, and vice versa.

Two facts, a and b, are equal if, for each property present on a, there is an equal fact property present on b and vice versa.

Two fact properties are equal if they meet the relevant criterion defined below:

  • Two {id} properties are equal if they have the same string value.
  • Two {dimensions} properties, a and b, are equal if, for every dimension in a the same dimension is present in b with an equal dimension value and vice versa.
  • Two {value} properties are equal if they are both "nil" or they have the same actual value based on the facts' datatype.
  • Two {decimals} properties are equal if they have the same integer value.
  • Two {links} properties, a and b, are equal if, for every link group in a there is a link group in b with the equal {group}, {link type} and {target facts} properties, and vice versa. Two {target fact} properties, tfa and tfb are equal if each fact in tfa is equal to the corresponding fact in tfb.

Two dimension values are equal if they meet the relevant criterion defined below:

  • Two concept core dimension values are equal if the namespace name and local name for both values are equal.
  • Two entity core dimension values are equal if the {scheme} and {identifier} properties have the same string values.
  • Two period core dimension values are equal if they denote the same time interval as defined in ISO 8601.
  • Two unit core dimension values are equal if the collection of {numerators} measures for both are equal, and the {denominators} property is either absent for both, or is the same collection of measures. Two measures are equal if they have the same namespace name and local name. Both {numerators} and {denominators} are unordered collections.
  • Two language core dimension values are equal if they have the same case-insensitive string value.
  • Two note id core dimension values are equal if they have the same string value.
  • Two taxonomy-defined dimension values if they have the same actual value based on the dimension's datatype.

4.2 Equivalence definitions

Two reports, A and B, are equivalent under this model if, for every fact in A, there is at least one equivalent fact in B, and vice versa.

Two facts, a and b, are equivalent if, for each property on a, there is an equivalent fact property present on b and vice versa.

Two fact properties are equivalent if they meet the relevant criterion for equal fact properties with the following modifications:

  • Two {id} property values are always considered equivalent (i.e. they are ignored for the purposes of establishing equivalence).
  • Similarly, when considering the equivalence of {dimensions} properties, two note id core dimensions are always considered equivalent.
  • Facts in the {target facts} properties of each link group in the {links} properties need only meet the requirements of equivalent facts.

The above definition does not require equivalent reports to have the same number of facts. Multiple equivalent facts in one report can be considered equivalent to a single fact in the other.

Appendix A References

BCP47
IETF. " BCP47: Tags for Identifying Languages "
(See https://tools.ietf.org/html/bcp47)
DIMENSIONS
XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hern√°ndez-Ros
, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
DTR STRUCTURE
XBRL International Inc. "Data Types Registry - Structure 1.1"
Mark GoodhandHugh WallisPaul Warren.

(See https://www.xbrl.org/Specification/dtr/CR-2018-01-17/dtr-structure-1.1-CR-2018-01-17.html)
EXTENSIBLE ENUMERATIONS 2.0
XBRL International Inc.. "Extensible Enumerations 2.0"
Mark Goodhand
, and Paul Warren.
(See https://www.xbrl.org/Specification/extensible-enumerations-2.0/CR-2018-04-23/extensible-enumerations-2.0-CR-2018-04-23.html)
IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.

(See http://www.ietf.org/rfc/rfc2119.txt)
ISO8601
International Standards Organisation. " ISO 8601 international standard numeric date and time representations. "
(See http://www.iso.ch/)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2013-02-20"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html)
XML Names
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Third Edition)"
(See http://www.w3.org/TR/2009/REC-xml-names-20091208)
XML Schema Datatypes
W3C (World Wide Web Consortium). "XML Schema Part 2: Datatypes Second Edition"
Paul V. Biron
, and Ashok Malhotra.
(See http://www.w3.org/TR/xmlschema-2/)
XML Schema Structures
W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson
, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/)
xBRL-XML
XBRL International Inc.. "xBRL-XML: XML Mappings for the Open Information Model 1.0"
Paul Warren
, and Herm Fischer.
(See https://specifications.xbrl.org/release-history-open-information-model-xbrl-xml.html)

Appendix B Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix C Document History (non-normative)

DateAuthorDetails
13 January 2016Paul Warren

First Public Working Draft

14 December 2016Paul Warren

Candidate Recommendation

02 May 2017Paul Warren

Second Candidate Recommendation

12 December 2018Paul Warren

Third Candidate Recommendation

12 June 2019Paul Warren

Fourth Candidate Recommendation

Appendix D Errata Corrections incorporated in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Specification Maintenance Working Group (SWG) up to and including 12 June 2019. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.