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, context, duplicate, DTS, fact, footnote, resource, tuple and XBRL instance 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.

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

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

3.2 Reports

The top-level component is a report.

3.3 Facts

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

A numeric fact is a fact with a datatype that is derived from the XML Schema type of xsd:decimal.

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 Schema document references

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

Explicit dimensions will have a type of xsd:QName, but it should be noted that a type of xsd: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 DTS.

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

3.6 Links

Links represent relationships between facts in a report.

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

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 are both "nil" or they have the same actual value based on the facts' datatype.
• 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 case-insensitive string value.
• Two note id core dimension values are equal if they have the same string value.
• Two taxonomy-defined dimension values if they have the same actual value based on the dimension's datatype.

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