1 Introduction

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

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

1.1 Scope

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

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

The supported specifications are:

XBRL v2.1 [XBRL 2.1]
XBRL Dimensions v1.0 [DIMENSIONS]
Extensible Enumerations v2.0 [EXTENSIBLE ENUMERATIONS 2.0]

1.2 Terminology

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

The keywords concept, fact, footnote, and taxonomy, as well as the terms nillable and abstract as applied to concepts, are to be interpreted as described in the XBRL specification [XBRL 2.1].

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

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

1.2.1 Collections

This specification uses the following terms to refer to collections. The use of these terms indicates whether the order and uniqueness of members is significant under the model, and thus whether these properties need to be preserved when transforming reports.

A list is an ordered sequence of members. Members may be repeated within the list.

An unordered collection is a collection that may contain repeated members. The number of times that each member appears is significant, but the order between them is not. Also known as a bag or multi-set.

A set is an unordered collection that contains no repeated members.

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	https://xbrl.org/2021
xbrli	http://www.xbrl.org/2003/instance
xs	http://www.w3.org/2001/XMLSchema
enum2	http://xbrl.org/2020/extensible-enumerations-2.0
`oime`	`http://www.xbrl.org/2021/oim/error`

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

2 Processors

This specification defines two classes of processors:

A conformant processor is any software that consumes data that conforms to the model defined in this document. A conformant processor MUST apply the constraints defined within this specification and raise an error with the specified code if any of the constraints are not satisfied.
A validating conformant processor is a conformant processor which additionally applies all constraints defined by the supported specifications and supported DTR types for an xBRL-XML [xBRL-XML] representation of the data in a successfully-created model. The appropriate error codes from those specifications MUST be raised if it is not possible to construct an xBRL-XML representation that satisfies all such constraints.

3 XBRL Report Model

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

3.1 Datatypes

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

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

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

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

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

3.1.1 Data Type Registry

The Data Types Registry (DTR) [DTR STRUCTURE] defines a set of additional datatypes which XBRL Processors may optionally support. A number of DTR types are referenced directly by this specification, and are referred to as supported DTR types.

The supported DTR types are:

dtr-type:domainItemType
dtr-type:noLangTokenItemType
dtr-type:noLangStringItemType
dtr-type:prefixedContentItemType
dtr-type:prefixedContentType
dtr-type:SQNameType
dtr-type:SQNameItemType
dtr-type:SQNamesType
dtr-type:SQNamesItemType

Some DTR types include additional validation rules as part of their registry definition. Validating conformant processors are required to apply such rules to supported DTR types (see Section 2).

3.2 Reports

The top-level component is a report.

Component: Report

Properties:

{taxonomy}

A list of URLs to XML Schema document that together identify the taxonomy for the report. The list MUST NOT be empty (oime:noTaxonomy).

{facts}

A set of facts.

{base-url}

An optional URL recording the location from which the report was loaded (or an explicitly specified alternative base URL). {base-url} MUST be an absolute URL (oime:invalidBaseURL).

This URL MAY be used for resolving relative URLs appearing as fact and dimension values within the report, although such resolution will depend on the definition of the concepts and dimensions involved and is not prescribed by this specification.

Constraints:

If a processor cannot obtain a valid taxonomy from the URLs in the {taxonomy} property, it MUST raise the error code oime:invalidTaxonomy, and MAY optionally raise a more specific error code prescribed by a supported specification in addition. Note that full validation of all constraints in supported specifications is only required of validating conformant processors. A processor MAY make use of URL remappings when resolving a URL.

Processors MUST support http, https and file scheme URLs in the {taxonomy} property. Processors MAY support other schemes, but such use is discouraged as they may not be supported in all processors. Use of absolute file URLs is also discouraged, as reports using this are unlikely to be portable.

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

3.3 Facts

Component: Fact

A fact is a discrete piece of information in an XBRL Report. All facts have the following properties.

Properties:

{id}

A unique identifier for the fact. The value MUST be an NCName (oime:invalidFactId), and MUST be unique across all facts within the report (oime:duplicateFactId). This property MUST be present on all facts (oime:missingFactId).

{id} attributes can be useful in providing traceability of facts through different syntactic representations, but do not form part of the semantic information provided by a report.

{dimensions}

A set of dimensions. The set may contain at most one of each core dimension. The set may contain multiple taxonomy defined dimensions, but their {name} properties MUST be unique within the set oime:duplicateFactDimension.

{links}

A set of link groups associated with the fact.

{value}

The value associated with this fact. This may be the special value "nil". The meaning of a fact reported as "nil", the distinction between this and a fact that is not reported, or a fact reported with an empty, or zero, value (where applicable) is implementation dependent.

{decimals}

The precision of the value, expressed as a number of decimal places, or "infinity", indicating that the value is infinitely precise.

Constraints:

If the fact's {value} is "nil", the fact MUST be nillable; otherwise, the {value} MUST be in the value space of the fact's base datatype (oime:invalidFactValue). Note that full validation against the fact's datatype and, in the case of supported DTR types, the DTR definition, is only required of validating conformant processors. The oime:invalidFactValue MAY be used for such full validation.

The {decimals} property MUST be present on, and MUST only be present on, non-nil numeric facts (oime:misplacedDecimalsProperty).

A fact's datatype MUST NOT be a complex type with complex content (oime:unsupportedConceptDataType).

If the fact's datatype is dtr-type:prefixedContentItemType, or a type derived from dtr-type:prefixedContentItemType that is not supported by the processor, the processor MUST raise oime:unsupportedConceptDataType.

The use of oime:invalidFactValue is optional for full fact validation because it is recognised that processors doing this validation may already have existing error codes, and it may not be straightforward to replace or augment these with oime:invalidFactValue.

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

A fact's base datatype is the XML Schema primitive type from which the fact's datatype is derived.

A fact is nillable if the concept identified by the fact's concept core dimension is nillable.

A numeric fact is a fact with a datatype that is derived from the XML Schema types of xs:decimal, xs:double or xs:float.

A non-numeric fact is any fact that is not a numeric fact.

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

xs:language
xs:Name
dtr-type:domainItemType
dtr-type:noLangTokenItemType
dtr-type:noLangStringItemType

A non-text fact is any fact that is not a text fact.

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

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

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

3.4 Dimensions

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

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

Component: Concept Core Dimension

Properties:

{name}

The expanded name corresponding to xbrl:concept

{value}

An expanded name identifying an XBRL concept.

Constraints:

The concept core dimension MUST be present on all facts (oime:missingConceptDimension).

The concept core dimension MUST identify a concept from the taxonomy (oime:unknownConcept).

The identified concept MUST NOT be abstract (oime:valueForAbstractConcept).

Component: Entity Core Dimension

The entity core dimension represents the primary legal entity (person or organisation) associated with a fact.

Properties:

{name}

The expanded name corresponding to xbrl:entity

{scheme}

A URI denoting the scheme from which an identifier is drawn.

{identifier}

A string identifying the entity to which the fact relates.

Constraints:

The entity core dimension MUST NOT have a scheme of 'https://xbrl.org/2021/entities' with an identifier of 'NA' (oime:invalidUseOfReservedIdentifier).

The entity core dimension is optional, and MAY be omitted if there is no primary legal entity associated with a fact, either because the fact does not relate to a legal entity, or because the fact captures a transaction or relationship between two or more legal entities with equal standing.

As defined in [xBRL-XML], the special entity with scheme of 'https://xbrl.org/2021/entities' and identifier 'NA' is used to represent the absence of this dimension in xBRL-XML syntax.

Component: Period Core Dimension

The period core dimension represents the period of time, or instant, to which a fact is applicable. Whilst the xBRL-XML representation uses different elements to represent instants and durations, this specification uses a common model for both in the form of an time interval as defined in ISO 8601 [ISO8601], with instants being represented using a zero-length time interval.

Properties:

{name}

The expanded name corresponding to xbrl:period

{interval}

A time interval, as defined in ISO 8601. The time interval MAY be zero-length (i.e. start and end at the same instant), denoting an instant in time. The time interval MAY be defined in local time (i.e. without a time zone designator) in which case processors MUST NOT assume a particular time zone, but MUST preserve the information that the time interval is in local time.

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

Constraints:

If the fact's period type is duration, the period core dimension is optional, and if present {interval} MUST be a non-zero length time interval (oime:invalidPeriodDimension).

If the fact's period type is instant, the period core dimension MUST be present (oime:missingPeriodDimension) and {interval} MUST be a zero-length time interval (oime:invalidPeriodDimension).

Note that as defined in [xBRL-XML], the absence of the period core dimension is represented by the special value of "forever" in xBRL-XML syntax.

A fact's period type is the value of the @periodType attribute on the schema definition of the concept identified by the fact's concept core dimension, and is either duration or instant.

Component: Unit Core Dimension

Properties:

{name}

The expanded name corresponding to xbrl:unit

{numerators}

An unordered collection of expanded names, identifying individual measures.

{denominators}

An optional, unordered collection of expanded names, identifying individual measures.

Constraints:

The unit core dimension MUST only be present on numeric facts (oime:misplacedUnitDimension). The unit core dimension is optional on numeric facts.

The unit core dimension MUST NOT have a single numerator of xbrli:pure with no denominators (oime:illegalPureUnit). The xbrli:pure measure used in xBRL-XML is mapped to a fact with an absent unit core dimension in this model (see [xBRL-XML]).

Component: Language Core Dimension

Properties:

{name}

The expanded name corresponding to xbrl:language

{language}

A string specifying the language in which the fact is reported. The string MUST be a valid BCP 47 [BCP47] language code oime:invalidLanguage.

Constraints:

The language core dimension MUST only be present on text facts (oime:misplacedLanguageDimension) and is optional on such facts.

Note that BCP 47 language codes are case insensitive, and whilst there are conventions for the capitalisation of these strings, differences in capitalisation do not convey different codes. See Section 5.2.

Component: Note ID core dimension

The note ID core dimension is used on xbrl:note facts in order to prevent multiple occurrences of such facts in a report from being classified as duplicates. xbrl:note facts are used to represent text footnotes (see Section 3.5.1.1).

Properties:

{name}

The expanded name corresponding to xbrl:noteId

{id}

A unique identifier for a fact.

Constraints:

The {id} property MUST be the same as the fact's {id} property (oime:invalidNoteIDValue).

This dimension MUST NOT be present on facts with a concept core dimension that is not xbrl:note (oime:misplacedNoteIDDimension).

3.5 Links

Links represent relationships between facts in a report. Links are a generalisation of the footnote mechanism defined in XBRL v2.1.

Component: Link group

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

Properties:

{group}

A URI identifying a grouping of links between facts.

{link type}

A URI identifying the type of the relationships between the facts in the group.

{target facts}

A list of facts which are the target of the links in the group.

3.5.1 Footnotes

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

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

3.5.1.1 The xbrl:note concept

This specification defines the xbrl:note concept, which is used to represent text footnotes as defined in XBRL v2.1, and for which specific handling is prescribed in xBRL-XML [xBRL-XML]. The xbrl:note concept has a datatype of xbrli:stringItemType.

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

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

Facts with a concept core dimension of xbrl:note:

MUST be included in the {target facts} property of at least one link group (oime:unusedNoteFact);
MUST have the language core dimension (oime:missingLanguageForNoteFact);
MUST have the note ID core dimension (oime:missingNoteIDDimension).
MUST NOT have the entity core dimension or period core dimension (oime:misplacedNoteFactDimension); and
MUST NOT have any taxonomy-defined dimensions (oime:misplacedNoteFactDimension).

Note that as text facts, xbrl:note facts cannot have the {decimals} property or unit core dimension.

4 Prefixed content

Some datatypes make use of prefixes as a shorthand notation for namespace URIs. Values for these datatypes make use of a map of prefix to namespace URI bindings that are in scope for the location in which the value appears. Neither the prefixes, nor the maps to which they refer form part of the model, and as such, special handling of these values is required in order to ensure that the model contains the referenced URIs rather than prefixes. Values for which this is required are referred to as prefixed content..

In an XML document, the map of prefixes to namespace URIs is provided by namespace bindings (see [XML Names]). Other formats based on this model typically use a prefix map.

Under this model, prefixed content is the value of any fact or taxonomy defined dimension with a datatype of, or derived from:

xs:QName
xbrli:QNameItemType
dtr-type:SQNameType
dtr-type:SQNameItemType
dtr-type:SQNamesType
dtr-type:SQNamesItemType
dtr-type:PrefixedContentType
dtr-type:PrefixedContentItemType

Processors cannot support arbitrary formats that may contain prefixed values, as it is necessary to know the details of the format in order to be able to reliably identify the prefixes. The dtr-type:PrefixedContentType and dtr-type:PrefixedContentItemType types exist to signal the presence of values that contain prefixes. These types may not be used directly, but processors MAY support specific types derived from them. Processors are required to signal an error if they encounter content using a derived type that they do not support (see the constraints on facts and taxonomy-defined dimensions).

5 Equality and equivalence

This specification provides separate definitions of equality and equivalence for facts and reports. Equivalent reports can be considered to convey the same semantic information. The stricter definition of equal reports additionally requires fact {id} properties to be equal.

5.1 Equality definitions

Two reports, A and B, are equal under this model if:

For every fact in A, there is an equal fact in B, and vice versa; and
The {taxonomy} component of A is equal to the {taxonomy} component of B.

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

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

Two {id} properties are equal if they have the same string value.
Two {dimensions} properties, a and b, are equal if, for every dimension in a the same dimension is present in b with an equal dimension value and vice versa.
Two {value} properties are equal if they satisfy the criteria for fact value equality.
Two {decimals} properties are equal if they have the same integer value.
Two {links} properties, a and b, are equal if, for every link group in a there is a link group in b with the equal {group}, {link type} and {target facts} properties, and vice versa. Two {target fact} properties, tfa and tfb are equal if each fact in tfa is equal to the corresponding fact in tfb.

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

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

5.1.1 Fact value equality

The {value} properties of two facts are equal if they have the same datatype and:

Both values are nil; or
They meet the relevant criterion below based on their datatype:
- For enumeration facts, the two values are the same set of expanded names.
- For prefixed content, the values are the same after resolving prefixes to namespace URIs. In the case of dtr-type:SQNamesItemType, the collection of values is treated as a list.
- For facts with a datatype of, or derived from, xbrli:languageItemType the values are equal if they have the same canonical language value.
- For all other datatypes, the values are equal if they have the same actual value based on the facts' datatype (see also Section 5.1.3 and Section 5.1.4).

5.1.2 Taxonomy-defined dimension value equality

Two taxonomy-defined dimension values are equal if they have the same datatype and:

Both values are nil; or
They meet the relevant criterion below based on their datatype:
- For prefixed content, the values are the same after resolving prefixes to namespace URIs. In the case of dtr-type:SQNamesType, the collection of values is treated as a list.
- For values with a datatype of, or derived from, xs:language the values are equal if they have the same canonical language value.
- For all other datatypes, the values are equal if they have the same actual value based on the dimension's datatype (see also Section 5.1.3).

5.1.3 URI comparison

Values for datatypes of, or derived from, xs:anyURI that are relative URIs are not absolutized prior to comparison. This means that two relative URIs with same value will be considered equal even though they appear in different documents with different locations. This specification does not specify where relative URIs appearing in fact and taxonomy-defined dimension values should be resolved relative to.

5.1.4 Comparison of xbrl:note facts

xbrl:note facts (see Section 3.5.1.1) are compared according to their datatype, which is derived from xsd:string. Under this model, the value is a serialisation of an XHTML fragment. It should be noted that when creating a model from an xBRL-XML [xBRL-XML] report, there is more than one valid serialisation of the same XHTML fragment (for example, attributes may be reordered), which could lead to equivalent XHTML not being considered equal under this model. This is only an issue when working with data derived from xBRL-XML, as other formats based on this model must treat the value as a simple string.

5.1.5 Canonical language value

A canonical language value is a BCP 47 language code whitespace normalised according to the requirements for xs:language and represented with all letters in lowercase.

BCP 47 language codes are case-insensitive. XBRL usage of language codes is based on the XML Schema xs:language datatype, which does not prescribe a case convention for the canonical lexical representation, which means that comparison of values in their XML Schema canonical lexical representation is not sufficient for establishing equality. It should be note that all-lowercase is not the conventional form for BCP 47 codes, but it is used here to avoid the need for parsing of BCP 47 codes.

5.2 Equivalence definitions

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

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

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

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

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

6 Duplicate and alternative facts

This specification provides a number of definitions relating to facts which may be considered duplicates or alternatives for certain purposes.

Two facts, a and b, are duplicate facts if for every dimension in the {dimensions} property of a, the same dimension is present in b with an equal dimension value and vice versa.

Duplicate facts are permitted under the model, but users may wish to prohibit some or all classes of duplicates in specific applications.

Alternative facts are facts that are distinguished by only the language or unit core dimensions. Unlike duplicate facts, alternative facts are dimensionally distinct, but users may wish to restrict their use as they may provide alternative, and potentially inconsistent, values for the same data point.

Neither duplicates nor alternative facts are considered an error by this specification. Specifications based on this model MAY prohibit certain classes of duplicates and alternative facts. This specification defines the standard error code, oime:disallowedDuplicateFacts, that MAY be used when prohibited duplicate facts are present in a report.

Under the model, all facts have a mandatory, unique {id} property, which may provide traceability to the source of each fact. This means that duplicate facts have a distinct identity.

Removing duplicate facts constitutes a modification to the report.

Where two reports differ only in the presence or absence of complete duplicates, they are considered to be equivalent reports.

6.1 Complete duplicates

Two duplicate facts are complete duplicates if:

they have satisfy the requirements for fact value equality; and
either:
- the {decimals} property is absent from both facts; or
- the {decimals} property has the same integer value.

6.2 Consistent duplicates

Two duplicate facts are consistent duplicates if they are complete duplicates, or:

they are numeric facts; and
they have reported values and precisions that are consistent with having been rounded from a single actual value, as described below.

6.2.1 Numeric value consistency

Consistency of numeric values is established by considering the interval represented by each reported fact, and ensuring that there is overlap between all intervals. For this purpose, the interval represented by a fact is taken to be a closed interval, centered on the reported value with a width of 10^-N, where N is the value of the fact's {decimals} property, or a zero-width interval if the {decimals} property is "infinity". Facts with the same {decimals} value MUST have the same numeric value in order to be considered consistent.

Numeric facts that are complete duplicates are also considered to be consistent duplicates.

The interval represented by a number of facts is shown below:

Fact A: 2,500 (decimals = -2) => [2450, 2550]
Fact B: 2,000 (decimals = -3) => [1500, 2500]
Fact C: 2,470 (decimals = -1) => [2465, 2475]

These facts are considered consistent as there is overlap between all intervals. These facts are all consistent with having been rounded from a single value in the range [2465, 2475].

The use of closed intervals allows consistency to be checked without knowing the rounding approach used, but makes the consistency check lax on certain edge cases.

It should be noted that the definition of consistency is not transitive; a fact A being consistent with both B and C does not imply that B and C are consistent.

6.3 Inconsistent duplicates

Two duplicate facts are inconsistent duplicates if:

they are numeric facts but are not consistent duplicates; or
they are non-numeric facts but do not satisfy the requirements for fact value equality.

6.4 Multi-language alternatives

Two facts, a and b, are multi-language alternatives if:

both facts are text facts;
for every dimension except the language core dimension in the {dimensions} property of a, the same dimension is present in b with an equal dimension value and vice versa; and
the facts have distinct values for the language core dimension.

The error code oime:illegalMultiLanguageAlternatives MAY be used by applications that prohibit multi-language alternatives.

6.5 Multi-unit alternatives

Two facts, a and b, are multi-unit alternatives if:

both facts are numeric facts;
for every dimension except the unit core dimension in the {dimensions} property of a, the same dimension is present in b with an equal dimension value and vice versa; and
the facts have distinct values for the unit core dimension.

The error code oime:illegalMultiUnitAlternatives MAY be used by applications that prohibit multi-unit alternatives.

Date	Author	Details
13 January 2016	Paul Warren	First Public Working Draft
14 December 2016	Paul Warren	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

Number	Date	Sections	Details
1.	29 September 2022	Section 3.4	Explicitly prohibit default dimension values from the model, and specify error code (#557).
2.	15 September 2022	Section 6	Add non-normative note clarifying that removing duplicates constitutes a modification to the report (#587).
3.	03 November 2021	Section 3.2	Specify error code to be used for unresolvable taxonomy URLs (#560).
4.	28 October 2021	Section 6.2.1	Expanded description of numeric consistency, removing dependency on Working Group Note (#559).

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

Definitions

Error codes

1 Introduction

1.1 Scope

1.2 Terminology

1.2.1 Collections

1.3 Namespaces and namespace prefixes

2 Processors

3 XBRL Report Model

3.1 Datatypes

3.1.1 Data Type Registry

3.2 Reports

3.3 Facts

3.4 Dimensions

3.5 Links

3.5.1 Footnotes

3.5.1.1 The xbrl:note concept

4 Prefixed content

5 Equality and equivalence

5.1 Equality definitions

5.1.1 Fact value equality

5.1.2 Taxonomy-defined dimension value equality

5.1.3 URI comparison

5.1.4 Comparison of xbrl:note facts

5.1.5 Canonical language value

5.2 Equivalence definitions

6 Duplicate and alternative facts

6.1 Complete duplicates

6.2 Consistent duplicates

6.2.1 Numeric value consistency

6.3 Inconsistent duplicates

6.4 Multi-language alternatives

6.5 Multi-unit alternatives

Appendix A References

Appendix B Intellectual property status (non-normative)

Appendix C Document History (non-normative)

Appendix D Errata Corrections incorporated in this document