1 Introduction

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].

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/*
xbrl	http://www.xbrl.org/CR/2019-06-12
xsd	http://www.w3.org/2001/XMLSchema
link	http://www.xbrl.org/2003/linkbase
xlink	http://www.w3.org/1999/xlink

2 Unsupported features

In order to achieve a simplified, logical 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 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 MUST only contain <xbrldi:explicitMember> and <xbrldi:typedMember> elements (xbrlxe:nonDimensionalSegmentScenarioContent).

2.1.2 Mixing segment and scenario elements

All hypercubes within the DTS of a report MUST be defined for use on the same container (either "segment" or "scenario") (xbrlxe:inconsistentDimensionsContainer). The container that is not used for dimensions MUST be empty or absent in all contexts in the 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, the following data types (xbrlxe:unsupportedConceptDataType):

xbrli:fractionItemType

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. Any required linkbases should be included by reference from an included XML Schema document.

2.1.9 Use of 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 XBRL v2.1 specification;
The current version of the XBRL Link Role Registry; or
The DTS that would be obtained if only the instance's <schemaRef> elements are considered

2.1.10 Unlinked footnotes

All <xbrl: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 MUST NOT contain any @xml:base attributes (xbrlxe:unsupportedXmlBase).

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 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 (non-GL)

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. This document is intended to define a bi-directional mapping between the Open Information Model and an XML document. 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:

{DTS references}

See DTS references

{facts}

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

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.

{link groups}

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.3.

{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 fact datatype is, or is derived from, xbrli:QNameItemType, dtr:SQNameItemType, dtr:SQNamesItemType then it is treated as prefixed content.

{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.

Prefixed content denotes values that contain prefixes that rely on namespace-prefix bindings in scope at the point of use. Such values are represented in the OIM model as a namespace-localname pair; the prefix does not form part of the model.

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 xsd: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 DTS references

Mapping: DTS Reference

A DTS reference component is represented by a <link:schemaRef> element. Direct references from an instance to a linkbase document (using a <link:linkbaseRef> element) are not supported by the OIM. <link:roleRef> elements are inserted as described below.

Properties:

{href}

The value of the @xlink:href attribute, excluding any fragment identifier.

When serialising to xBRL-XML, all DTS references 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 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.

3.3 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.4.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 http://www.xbrl.org/CR/2019-06-12, 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 <xbrl: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> 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 list of values of the xbrli:divide/xbrli:unitNumerator elements. Otherwise, {numerators} is the unordered list 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 list of values of the xbrli:divide/xbrli:unitDenominator elements. Otherwise, {denominators} is an empty list.

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 child element has a datatype of, or derived from, xsd:QName, dtr:SQNameType or dtr:SQNamesType then it is treated as prefixed content.

3.4 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.4.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.4.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

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

Candidate Recommendation 12 June 2019

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-standard role types and arcrole types

2.1.10 Unlinked footnotes

2.1.11 Use of `@xml:base` attribute

2.2 Other unsupported features

3 XBRL Report Model (non-GL)

3.1 Facts

3.1.1 Generating fact ID values

3.2 DTS references

3.3 Dimensions

3.4 Links

3.4.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

Candidate Recommendation 12 June 2019

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-standard role types and arcrole types

2.1.10 Unlinked footnotes

2.1.11 Use of @xml:base attribute

2.2 Other unsupported features

3 XBRL Report Model (non-GL)

3.1 Facts

3.1.1 Generating fact ID values

3.2 DTS references

3.3 Dimensions

3.4 Links

3.4.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