1 Introduction

This document defines a bi-directional mapping between the Open Information Model and an XBRL v2.1 conformant XML document.

1.1 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 numeric fact, text fact, OIM processor and supported specification are to be interpreted as described in the Open Information Model specification [OIM].

The keywords fragment identifier are to be interpreted as described in the URI specification [URI].

The keyword DTS is to be interpreted as described in the XBRL v2.1 Specification [XBRL 2.1].

The keywords typed dimension are to be interpreted as described in the XBRL Dimensions v1.0 Specification [DIMENSIONS].

An xBRL-XML report is any valid XBRL instance as defined by [XBRL 2.1].

An OIM-compatible xBRL-XML report is an xBRL-XML report that complies with the constraints defined in Section 2.1.

1.2 Documentation conventions

1.2.1 Error codes

QNames in parenthetical red text after a "MUST" or "MUST NOT" statement prescribe standardised error codes to be used if the preceding condition is violated.

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/*
link	http://www.xbrl.org/2003/linkbase
xbrl	https://xbrl.org/2021
xbrldi	http://xbrl.org/2006/xbrldi
xbrli	http://www.xbrl.org/2003/instance
xlink	http://www.w3.org/1999/xlink
xml	http://www.w3.org/XML/1998/namespace
xs	http://www.w3.org/2001/XMLSchema
`xbrlxe`	`https://xbrl.org/2021/xbrl-xml/error`

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

2 Unsupported features

In order to achieve a simplified view of XBRL data, the OIM only supports a subset of the functionality available in the XBRL v2.1 and related specifications.

2.1 Constraints

This section defines a set of constraints that an XBRL instance MUST comply with in order to be represented in the model. An OIM Processor MUST raise an error when consuming an XBRL instance that does not meet these constraints.

2.1.1 Non-dimensional segment/scenario content

The <xbrli:segment> and <xbrli:scenario> elements in contexts used by facts in an XBRL instance MUST only contain <xbrldi:explicitMember> and <xbrldi:typedMember> elements (xbrlxe:nonDimensionalSegmentScenarioContent).

2.1.2 Mixing segment and scenario elements

All <xbrldi:explicitMember> and <xbrldi:typedMember> elements in a report MUST appear in the same type of container element (either <xbrli:segment> or <xbrli:scenario> ) (xbrlxe:inconsistentDimensionsContainer). The container that is not used for dimensions MUST be empty or absent in all contexts used by facts in an XBRL instance (xbrlxe:unexpectedContextContent).

2.1.3 Complex-typed dimensions

The XBRL instance MUST NOT make use of any typed dimensions that have a complex type (xbrlxe:unsupportedComplexTypedDimension).

2.1.4 Tuples

The XBRL instance MUST NOT include any tuples (xbrlxe:unsupportedTuple).

2.1.5 Unsupported concept data types

The XBRL instance MUST NOT make use of any concepts with a type of, or derived from xbrli:fractionItemType (xbrlxe:unsupportedFraction).

2.1.6 Use of non-standard footnote resource roles

The XBRL instance MUST NOT contain any footnote resources with a role other than http://www.xbrl.org/2003/role/footnote. Footnote resources MAY be present with an unspecified role (xbrlxe:nonStandardFootnoteResourceRole).

2.1.7 Use of zero-precision numeric facts

The XBRL instance MUST NOT contain any facts that have a precision of zero (xbrlxe:unsupportedZeroPrecisionFact).

2.1.8 Direct references to linkbase documents

The XBRL instance MUST NOT contain any <linkbaseRef> elements (xbrlxe:unsupportedLinkbaseReference). Any required linkbases should be included by reference from an included XML Schema document.

2.1.9 Use of non-discoverable, non-standard role types and arcrole types

The XBRL instance MUST NOT contain any <roleRef> or <arcroleRef> elements that reference role types or arcrole types that are not defined in (xbrlxe:unsupportedExternalRoleRef):

The current version of the XBRL Link Role Registry [LRR STRUCTURE]; or
The DTS that would be obtained if only the instance's <schemaRef> elements are considered.

2.1.10 Unlinked footnotes

All <xbrli:footnote> elements MUST be the target of at least one footnote relationship (xbrlxe:unlinkedFootnoteResource).

2.1.11 Use of `@xml:base` attribute

The XBRL instance MAY have an @xml:base attribute on the root ( <xbrli:xbrl> ) element. The @xml:base attribute MUST NOT be present on any other element (xbrlxe:unsupportedXmlBase).

2.1.12 Unsupported legacy datatypes and derivation restrictions

The Open Information Model prohibits certain legacy datatypes and datatype restriction methods for taxonomy-defined dimensions. See taxonomy-defined dimensions in the Open Information Model [OIM] for details.

2.2 Other unsupported features

In addition, it should be noted that the model does not support XML custom attributes (i.e. attributes that are permitted by the XBRL v2.1 specification [XBRL 2.1], but which are not explicitly defined by any supported specification). Unlike the features listed above, OIM Processors MUST NOT treat XML custom attributes as an error, but the information present in such custom attributes will not be present in the resulting model.

3 XBRL Report Model

The section describes how each component defined in the Open Information Model is obtained from a valid XBRL instance document and its accompanying Discoverable Taxonomy Set. The transformation from model to XML is not explicitly described, but may be inferred from the XML to Model mappings, taken in conjunction with the constraints defined in the XBRL v2.1 [XBRL 2.1] and XBRL Dimensions v1.0 [DIMENSIONS] specifications.

The starting point of the model is the report component, which corresponds to an XBRL XML instance document. Other components are only included in the model where they are referenced, directly or indirectly, from the report component.

Mapping: Report

Properties:

{taxonomy}

A list of the values of the @xlink:href attribute on all <link:schemaRef> elements in the XBRL instance. Note that direct references to linkbase documents (using <link:linkbaseRef> elements) are not supported. Use of <link:roleRef> and <link:arcroleRef> elements is constrained (see Section 2.1.9), and special handling is applied when serialising to xBRL-XML, as described below.

{facts}

A set of fact components corresponding to all fact elements present in the instance document.

{base-url}

Inclusion of this property in the model is optional, but if included then it MUST be the value of the @xml:base attribute on the <xbrli:xbrl> element, if present, otherwise the absolute URL from which the XBRL instance was obtained.

When serialising to xBRL-XML, all URLs in the {taxonomy} property should be serialised to a <link:schemaRef> element. In addition, if the report makes use of any role types or arcrole types that are not defined in the XBRL v2.1 specification then <link:roleRef> and <link:arcroleRef> elements should be inserted as follows:

If the role type or arcrole type is defined by a <link:roleType> or <link:arcroleType> element in the report's DTS, then a <link:roleRef> or <link:arcroleRef> element referencing that definition should be included in the xBRL-XML document.
If the role type or arcrole type is defined by the current version of the XBRL Link Role Registry [LRR STRUCTURE] then a <link:roleRef> or <link:arcroleRef> referencing the relevant <link:roleType> or <link:arcroleType> element from the registry should be included in the xBRL-XML document.
Otherwise, the processor MUST raise an xbrlxe:nonStandardRoleDefinitionNotInDTS error.

When serialising to xBRL-XML, inclusion of @xml:base attribute on the <xbrli:xbrl> element is optional, but if present it MUST be set to the value of the {base-url} property of the {report}.

3.1 Facts

A fact element is an XML element in the xbrli:item substitution group.

Mapping: Fact

A fact component is represented by a fact element.

Properties:

{id}

The value of the @id attribute, if present, otherwise a value generated as described in Section 3.1.1. The OIM specification requires that the {id} property is unique across all facts in the report.

{links}

A collection of link group components, corresponding to the elements connected to the fact by footnote relationships. See the link group component for details.

{dimensions}

The set of dimension OIM components associated with the fact. These are described in Section 3.2.

{value}

The content of the element.

If the fact is an enumeration fact, the value property is either the single expanded name, or the set of expanded names, represented using expanded name URI notation, as defined in [EXTENSIBLE ENUMERATIONS 2.0].
If the {value} is prefixed content then any prefixes in the value are resolved to namespace URIs with reference to in-scope namespace bindings (see [XML Names]).

{decimals}

For numeric facts, the value of the @decimals, if present, otherwise the value of decimals that may be inferred from the @precision attribute, as described in section 4.6.6 of [XBRL 2.1], or "infinity" if the value is INF. Absent for other facts.

The fact context is the <xbrli:context> element with an @id attribute that corresponds to the @contextRef attribute on the element representing a fact.

3.1.1 Generating fact ID values

The OIM {id} property on facts is mandatory, but the @id attribute on facts elements in an xBRL-XML report is optional. When converting an xBRL-XML report to an OIM model, ID values MUST be generated as described here in order to enable traceability of facts back to elements in the XML syntax.

If the @id attribute is present, then its value is used as the {id} property;
otherwise, a generated position-based ID should be used, provided that no element in the document has an XML ID attribute with that value;
otherwise, a generated position-based ID should be used with a suffix fo "_N" where N is the smallest positive integer that results in a value that is not the value of an XML ID attribute on an element.

Note that when checking for conflicts with existing XML ID attributes, all attributes that are of type xs:ID should be considered, not just those appearing on XBRL facts.

A position-based ID is a string value that uniquely identifies an XML element based on its position within the XML document, as defined here. The value is the string "e." followed by one or more integers separated by ".". Each successive integer n identifies the nth child element of the previously identified elements. The first integer identifies the root element of the document, and will always be the number 1.

Example 1: Resolving IDs

For example, the position-based ID e.1.5 identifies the 5th child of the root element in an XML document.

The construction of position-based IDs intentionally mirrors that of the XPointer element scheme [XPOINTER], and allows an ID to be resolved as follows:

If an element exists with the given ID, then that element is selected;
Otherwise, construct an XPointer by removing the "e" prefix and any underscore-separated suffix, and replacing all occurrences of "." with "/".

For example, given a value of e.1.5, if no element exists with that ID, then the element selected by the XPointer element(/1/5) should be selected.

It should be noted that as the OIM does not permit tuples, position-based IDs for facts will always be of the form e.1.N

3.2 Dimensions

Mapping: Concept Core Dimension

Properties:

{name}

The expanded name corresponding to xbrl:concept

{value}

The name of the XML element representing the fact.

When serialising to xBRL-XML, facts with a concept core dimension of xbrl:note are converted to <link:footnote> elements, as described in Section 3.3.1.

Mapping: Entity Core Dimension

The entity core dimension is present on all facts unless the xbrli:entity/xbrli:identifier element within the fact context as a value of NA and a @scheme attribute of https://xbrl.org/2021/entities, in which case the entity core dimension is absent.

Properties:

{name}

The expanded name corresponding to xbrl:entity

{scheme}

The value of the @scheme attribute on the xbrli:entity/xbrli:identifier element within the fact context.

{identifier}

The value of the xbrli:entity/xbrli:identifier element within the fact context.

Mapping: Period Core Dimension

The period core dimension is present on all facts except those where the <xbrli:period> element within the fact context contains the <xbrli:forever> element, in which case the period core dimension is absent.

Properties:

{name}

The expanded name corresponding to xbrl:period

{interval}

The value of the interval property is determined by the contents of the <xbrli:period> element within the fact context as follows:

If the <xbrli:period> element contains an <xbrli:instant> element, then {interval} is a zero-length duration, starting and ending at the time specified.
Otherwise, the duration starting at the time specified by the <xbrli:startDate> element and ending at the time specified by the <xbrli:endDate> element.

Note: If <xbrli:startDate> , <xbrli:endDate> , and <xbrli:instant> elements are specified with no time component, then they are to be interpreted as per section 4.7.2 of the XBRL v2.1 specification [XBRL 2.1]. This amounts to treating dates in an <xbrli:startDate> element as referring to midnight at the start of that day, and dates in <xbrli:endDate> and <xbrli:instant> elements as referring to midnight at the end of that day.

The fact unit is the <xbrli:unit> element with an @id attribute that corresponds to the @unitRef attribute on the element representing a fact, if present.

Mapping: Unit Core Dimension

The unit core dimension is present on facts which have a fact unit with a value other than a single measure of xbrli:pure, and absent on all other facts.

Properties:

{name}

The expanded name corresponding to xbrl:unit

{numerators}

If the fact unit contains an <xbrli:divide> element, then {numerators} is the unordered collection of values of the xbrli:divide/xbrli:unitNumerator elements. Otherwise, {numerators} is the unordered collection of values of the xbrli:measure elements.

As noted above, if the fact unit consists of a single measure xbrli:pure then the unit core dimension is absent.

{denominators}

If the fact unit contains an <xbrli:divide> element, then {denominators} is the unordered collection of values of the xbrli:divide/xbrli:unitDenominator elements. Otherwise, {denominators} is an empty collection.

Mapping: Language Core Dimension

The language core dimension is present on text facts which have an in scope language declaration, as described below. For all other facts, the language core dimension is not present.

Properties:

{name}

The expanded name corresponding to xbrl:language

{language}

The language identified by any @xml:lang declaration that is in scope, as described in section 2.12 of [XML], for the element representing the fact. If there is no such declaration in scope, or if the in-scope declaration is the empty string, then this dimension is absent from the fact. Only language declarations within the XML document may be used: the language MUST NOT be taken from external transport protocols, as allowed for by [XML].

Mapping: Taxonomy-defined Dimension

A fact will have one taxonomy-defined dimension for each <xbrldi:explicitMember> or <xbrldi:typedMember> element in the <xbrli:segment> or <xbrli:scenario> elements of the fact context.

Properties:

{name}

The value of the @dimension attribute of the <xbrldi:explicitMember> or <xbrldi:typedMember> element that represents this dimension.

{value}

If the dimension is represented by an <xbrldi:explicitMember> element, then the value of that element. The value is treated as prefixed content;
Otherwise, the value of the single child of the <xbrldi:typedMember> element representing this dimension.

If the value is prefixed content then any prefixes in the value are resolved to namespace URIs with reference to in scope namespace bindings (see [XML Names]).

When serialising to xBRL-XML, all taxonomy-defined dimensions for all facts in a report are serialised to the same container element (either <xbrli:segment> or <xbrli:scenario> ). If the report's DTS contains hypercubes for a single container, then that container is used for all taxonomy-defined dimensions. If the DTS contains hypercubes for both containers, the container should be chosen so as to achieve dimensional validity for all facts, if possible. If this is not possible, the container should be chosen arbitrarily, and appropriate XBRL Dimensions [DIMENSIONS] errors raised. If the report's DTS does not contain any hypercubes, or if dimensional validity can be achieved using either container, <xbrli:scenario> should be used for all dimensions.

Although it is expected that taxonomies will only define usable hypercubes for a single container element, some taxonomies define hypercubes containing a single dimension with no members and no default in order to prevent the use of other dimensional container.

3.3 Links

Footnotes in an XBRL XML instance document are represented in the OIM as links to other facts.

Mapping: Link group

A link group exists for a fact for each unique combination of extended link role and arcrole on the set footnote relationships for which the fact is the source. The link group has the following properties:

Properties:

{group}

The value of the @xlink:role attribute on the <link:footnoteLink> element containing <link:footnoteArc> element that defines this footnote.

{link type}

The value of the @xlink:arcrole attribute on the <link:footnoteArc> element that defines this footnote.

{target facts}

A list of facts corresponding to the targets of the footnote relationships for this group, ordered according to the values of the @order attributes on the defining <link:footnoteArc> elements. If the targets of footnote relationships are <link:footnote> elements, then xbrl:note facts are added to the report as described in Section 3.3.1.

Where multiple footnote relationships have the same value for the @order attribute on the defining <link:footnoteArc> , the facts are ordered by lexicographical sorting of the {id} property of the target fact.

A footnote relationship is an effective relationship defined by a <link:footnoteArc> element.

An effective relationship is a relationship present in the set of networks resulting from applying the rules of prohibiting and overriding relationships, as defined in section 3.5.3.9.7.5 of [XBRL 2.1].

3.3.1 Text footnotes

A text footnote fact is added to the report for each <link:footnote> element in the instance document.

Mapping: Text footnote fact

A text footnote fact is a fact with the following properties, corresponding to a <link:footnote> element.

Properties:

{id}

The value of the @id attribute on the <link:footnote> element, if present, otherwise a value generated as described in Section 3.1.1.

{dimensions}

A set containing the following dimensions:

A concept core dimension with a value of xbrl:note.
A taxonomy-defined dimension with name xbrl:noteId and the same value as the {id} property.
A language core dimension with the value of the @xml:lang declaration applicable to the <link:footnote> element, as described in section 2.12 of [XML], if any. This dimension should be omitted if there is no application declaration.

{value}

A string containing the <link:footnote> element serialised as described in serialising XML fragments in HTML 5.2, and in the context of a default namespace of:

http://www.w3.org/1999/xhtml

Elements in the above namespace MUST be serialised using the default namespace (see Example 2).

Note that the serialisation process includes only the contents of an element, so the <link:footnote> element itself is not included.

Example 2: Footnote serialisation

The following example is a footnote resource in an xBRL-XML document (XLink attributes omitted for clarity):

This example would result in an xbrl:note fact with a value of:

This is an <b>important</b> footnote

Date	Author	Details
03 January 2016		First Public Working Draft
14 December 2016		Candidate Recommendation
02 May 2017	Paul Warren	Second Candidate Recommendation
12 December 2018	Paul Warren	Third Candidate Recommendation
12 June 2019	Paul Warren	Fourth Candidate Recommendation
07 May 2020	Paul Warren	Fifth Candidate Recommendation
14 October 2020	Paul Warren	Sixth Candidate Recommendation
03 February 2021	Paul Warren	Seventh Candidate Recommendation
16 February 2021	Paul Warren	Eighth Candidate Recommendation
07 July 2021	Paul Warren	Nineth Candidate Recommendation
04 August 2021	Paul Warren	Proposed Recommendation
13 October 2021	Paul Warren	Recommendation

xBRL-XML: XML Mappings for the Open Information Model 1.0

Proposed Edited Recommendation 13 October 2021 with errata corrections to 15 February 2023

Status

Abstract

Table of Contents

Appendices

Table

Examples

Definitions

Error codes

1 Introduction

1.1 Terminology

1.2 Documentation conventions

1.2.1 Error codes

1.3 Namespaces and namespace prefixes

2 Unsupported features

2.1 Constraints

2.1.1 Non-dimensional segment/scenario content

2.1.2 Mixing segment and scenario elements

2.1.3 Complex-typed dimensions

2.1.4 Tuples

2.1.5 Unsupported concept data types

2.1.6 Use of non-standard footnote resource roles

2.1.7 Use of zero-precision numeric facts

2.1.8 Direct references to linkbase documents

2.1.9 Use of non-discoverable, non-standard role types and arcrole types

2.1.10 Unlinked footnotes

2.1.11 Use of `@xml:base` attribute

2.1.12 Unsupported legacy datatypes and derivation restrictions

2.2 Other unsupported features

3 XBRL Report Model

3.1 Facts

3.1.1 Generating fact ID values

3.2 Dimensions

3.3 Links

3.3.1 Text footnotes

Appendix A References

Appendix B Intellectual property status (non-normative)

Appendix C Document History (non-normative)

Appendix D Errata Corrections incorporated in this document

xBRL-XML: XML Mappings for the Open Information Model 1.0

Proposed Edited Recommendation 13 October 2021 with errata corrections to 15 February 2023

Status

Abstract

Table of Contents

Appendices

Table

Examples

Definitions

Error codes

1 Introduction

1.1 Terminology

1.2 Documentation conventions

1.2.1 Error codes

1.3 Namespaces and namespace prefixes

2 Unsupported features

2.1 Constraints

2.1.1 Non-dimensional segment/scenario content

2.1.2 Mixing segment and scenario elements

2.1.3 Complex-typed dimensions

2.1.4 Tuples

2.1.5 Unsupported concept data types

2.1.6 Use of non-standard footnote resource roles

2.1.7 Use of zero-precision numeric facts

2.1.8 Direct references to linkbase documents

2.1.9 Use of non-discoverable, non-standard role types and arcrole types

2.1.10 Unlinked footnotes

2.1.11 Use of @xml:base attribute

2.1.12 Unsupported legacy datatypes and derivation restrictions

2.2 Other unsupported features

3 XBRL Report Model

3.1 Facts

3.1.1 Generating fact ID values

3.2 Dimensions

3.3 Links

3.3.1 Text footnotes

Appendix A References

Appendix B Intellectual property status (non-normative)

Appendix C Document History (non-normative)

Appendix D Errata Corrections incorporated in this document

2.1.11 Use of `@xml:base` attribute