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.

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

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

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.

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

The top-level component is a report.

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.

3.3 Facts

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.

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

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.

Explicit dimensions will have a datatype of xs:QName, but it should be noted that a datatype of xs:QName does not imply that the dimension is explicit; it may be a QName typed dimension. The actual nature of the dimension can be determined from the taxonomy.

The set of taxonomy-defined dimensions associated with a fact does not include any explicit dimensions using a dimension default.

The base datatype of a typed dimension is the XML Schema primitive type from which the typed dimension's datatype is derived.

3.5 Links

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

5.1 Equality definitions

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

6.1 Complete duplicates

6.2 Consistent duplicates

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

6.3 Inconsistent duplicates

6.4 Multi-language alternatives

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

6.5 Multi-unit alternatives

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