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

Recommendation 13 October 2021

Copyright © XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/xbrl-xml/REC-2021-10-13/xbrl-xml-REC-2021-10-13.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>
Contributors:
Daniel Dracott, CoreFiling <djd@corefiling.com>
Eleanor Joslin, CoreFiling <ejj@corefiling.com>

Status

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.

Abstract

This document defines the mapping from the XML representation defined in XBRL v2.1 to the XBRL Open Information Model v1.0, a syntax-independent definition of the data represented by an XBRL v2.1 instance document.

Table of Contents

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

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

Examples

1 Resolving IDs
2 Footnote serialisation

Definitions

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)

Error codes

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


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

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
xbrlxehttps://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:

  1. 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.
  2. 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.
  3. 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.
{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):

<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

Appendix A References

DIMENSIONS
XBRL International Inc..
"XBRL Dimensions 1.0"
Ignacio Hernández-Ros
, and Hugh Wallis.
DTR STRUCTURE
XBRL International Inc.
"Data Types Registry - Structure 1.1"
Mark GoodhandHugh WallisPaul Warren.
EXTENSIBLE ENUMERATIONS 2.0
XBRL International Inc..
"Extensible Enumerations 2.0"
Mark Goodhand
, and Paul Warren.
HTML52
W3C (World Wide Web Consortium).
"HTML 5.2"
IETF RFC 2119
IETF (Internet Engineering Task Force).
"RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.
LRR STRUCTURE
XBRL International Inc.
"Link Role Registry - Structure 2.0"
Hugh Wallis
, and Walter Hamscher.
OIM
XBRL International Inc..
"XBRL Open Information Model"
Paul Warren.
URI
IETF (Internet Engineering Task Force).
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"
T. Berners-Lee
, L. Masinter, and R. Fielding.
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.
XML
W3C (World Wide Web Consortium).
"Extensible Markup Language (XML) 1.0 (Fifth Edition)"
Tim Bray
, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau.
XML Names
W3C (World Wide Web Consortium).
"Namespaces in XML 1.0 (Third Edition)"
XPOINTER
W3C (World Wide Web Consortium).
"XPointer Framework"
Paul Grosso
, Eve Maler, Jonathan Marsh, and Norman Walsh.

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
03 January 2016

First Public Working Draft

14 December 2016

Candidate Recommendation

02 May 2017Paul Warren

Second Candidate Recommendation

12 December 2018Paul Warren

Third Candidate Recommendation

12 June 2019Paul Warren

Fourth Candidate Recommendation

07 May 2020Paul Warren

Fifth Candidate Recommendation

14 October 2020Paul Warren

Sixth Candidate Recommendation

03 February 2021Paul Warren

Seventh Candidate Recommendation

16 February 2021Paul Warren

Eighth Candidate Recommendation

07 July 2021Paul Warren

Nineth Candidate Recommendation

04 August 2021Paul Warren

Proposed Recommendation

13 October 2021Paul Warren

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