Copyright © XBRL International Inc., All Rights Reserved.
Circulation of this Recommendation is unrestricted. This document is normative. 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.
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
A References
B Intellectual property status (non-normative)
C Document History (non-normative)
D Errata Corrections incorporated in this document
1 Namespaces and namespace prefixes
1 Resolving IDs
2 Footnote serialisation
Concept Core Dimension (Mapping)
Effective relationship
Entity Core Dimension (Mapping)
Fact (Mapping)
Fact context
Fact element
Fact unit
Footnote relationship
Language Core Dimension (Mapping)
Link group (Mapping)
Period Core Dimension (Mapping)
Position-based ID
Report (Mapping)
Taxonomy-defined Dimension (Mapping)
Text footnote fact (Mapping)
Unit Core Dimension (Mapping)
xbrlxe:inconsistentDimensionsContainer
xbrlxe:nonDimensionalSegmentScenarioContent
xbrlxe:nonStandardFootnoteResourceRole
xbrlxe:nonStandardRoleDefinitionNotInDTS
xbrlxe:unexpectedContextContent
xbrlxe:unlinkedFootnoteResource
xbrlxe:unsupportedComplexTypedDimension
xbrlxe:unsupportedExternalRoleRef
xbrlxe:unsupportedFraction
xbrlxe:unsupportedLinkbaseReference
xbrlxe:unsupportedTuple
xbrlxe:unsupportedXmlBase
xbrlxe:unsupportedZeroPrecisionFact
This document defines a bi-directional mapping between the Open Information Model and an XBRL v2.1 conformant XML document.
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].
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.
| 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].
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.
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.
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).
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).
The XBRL instance MUST NOT make use of any typed dimensions that have a complex type (xbrlxe:unsupportedComplexTypedDimension).
The XBRL instance MUST NOT make use of any concepts with a type of, or derived from xbrli:fractionItemType (xbrlxe:unsupportedFraction).
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).
The XBRL instance MUST NOT contain any facts that have a precision of zero (xbrlxe:unsupportedZeroPrecisionFact).
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.
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):
<schemaRef> elements are considered.
All <xbrli:footnote> elements MUST be the target of at least one footnote relationship (xbrlxe:unlinkedFootnoteResource).
@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).
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.
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.
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.
@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. @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:
<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. <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.
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}.
A fact element is an XML element in the xbrli:item substitution group.
A fact component is represented by a fact element.
@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.
@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.
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.
@id attribute is present, then its value is used as the {id} property;
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.
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:
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
xbrl:concept
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.
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.
xbrl:entity @scheme attribute on the xbrli:entity/xbrli:identifier element within the fact context.xbrli:entity/xbrli:identifier element within the fact context. <xbrli:period> element within the fact context contains the <xbrli:forever> element, in which case the period core dimension is absent.
xbrl:period
The value of the interval property is determined by the contents of the <xbrli:period> element within the fact context as follows:
<xbrli:period> element contains an <xbrli:instant> element, then {interval} is a zero-length duration, starting and ending at the time specified. <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.
xbrli:pure, and absent on all other facts.
xbrl:unit
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.
<xbrli:divide> element, then {denominators} is the unordered collection of
values of the xbrli:divide/xbrli:unitDenominator elements.
Otherwise, {denominators} is an empty collection.
xbrl:language @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].
<xbrldi:explicitMember> or <xbrldi:typedMember> element in the <xbrli:segment> or <xbrli:scenario> elements of the fact context.
@dimension attribute of the <xbrldi:explicitMember> or <xbrldi:typedMember> element that represents this dimension. <xbrldi:explicitMember> element, then the value of that element. The value is treated as prefixed content; <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.
Footnotes in an XBRL XML instance document are represented in the OIM as links to other facts.
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:
@xlink:role attribute on the <link:footnoteLink> element containing <link:footnoteArc> element that defines this footnote.The value of the @xlink:arcrole attribute on the <link:footnoteArc> element that defines this footnote.
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].
A text footnote fact is added to the report for each <link:footnote> element in the instance document.
<link:footnote> element.
@id attribute on the <link:footnote> element, if present, otherwise a value generated as described in Section 3.1.1.A set containing the following dimensions:
xbrl:note.xbrl:noteId and the same value as the {id} property. @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.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/xhtmlElements 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.
The following example is a footnote resource in an xBRL-XML document (XLink attributes omitted for clarity):
<link:footnote xmlns:xhtml="http://www.w3.org/1999/xhtml" ... > This is an <xhtml:b>important</xhtml:b> footnote </link:footnote>
This example would result in an xbrl:note fact with a value of:
This is an <b>important</b> footnote
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).
| 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 |
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 13 October 2021. 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.