Copyright © XBRL International Inc., All Rights Reserved.
Circulation of this Candidate Recommendation is unrestricted. This document is normative. Other documents may supersede this document. 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.
This document describes a syntax-independent model for business reports that conform to the XBRL v2.1 and XBRL Dimensions v1.0 specifications. The model is intended to enable easy and lossless transformation of a well defined set of semantics between a variety of different syntactic representations, including the XML syntax defined in the above specifications.
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.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 URI comparison
5.2 Equivalence definitions
A References
B Intellectual property status (non-normative)
C Document History (non-normative)
D Errata Corrections incorporated in this document
1 Namespaces and namespace prefixes
Component
Concept Core Dimension (Component)
Conformant processor
Core Dimension
Dimension
Entity Core Dimension (Component)
Enumeration fact
Equal dimension value
Equal fact property
Equal facts
Equal reports
Equivalent fact property
Equivalent facts
Equivalent reports
Fact (Component)
Fact datatype
Fact period type
Language Core Dimension (Component)
Link group (Component)
List
Nillable
Non-numeric fact
Non-text fact
Note ID core dimension (Component)
Numeric fact
Period Core Dimension (Component)
Prefixed content
Property
Report (Component)
Set
Supported specification
Taxonomy-defined Dimension (Component)
Text fact
Unit Core Dimension (Component)
Unordered collection
Validating conformant processor
XHTML fragment
xbrle:duplicateFactDimension
xbrle:duplicateFactId
xbrle:illegalPureUnit
xbrle:illegalStandardFootnoteTarget
xbrle:invalidDimensionValue
xbrle:invalidFactId
xbrle:invalidFactValue
xbrle:invalidLanguage
xbrle:invalidNoteIDValue
xbrle:invalidPeriodDimension 2
xbrle:invalidXHTMLFragment
xbrle:misplacedDecimalsProperty
xbrle:misplacedLanguageDimension
xbrle:misplacedNoteFactDimension 2
xbrle:misplacedNoteIDDimension
xbrle:misplacedUnitDimension
xbrle:missingConceptDimension
xbrle:missingFactId
xbrle:missingLanguageForNoteFact
xbrle:missingNoteIDDimension
xbrle:missingPeriodDimension
xbrle:noTaxonomy
xbrle:unknownConcept
xbrle:unknownDimension
xbrle:unusedNoteFact
xbrle:valueForAbstractConcept
xbrle:xhtmlElementInNonDefaultNamespace
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.
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:
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].
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.
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.
Prefix | Namespace URI |
---|---|
dtr-type | http://www.xbrl.org/dtr/type/* |
xbrl | http://www.xbrl.org/CR/2020-05-06 |
xbrli | http://www.xbrl.org/2003/instance |
xs | http://www.w3.org/2001/XMLSchema |
enum2 | http://xbrl.org/CR/2018-04-23/extensible-enumerations-2.0 |
xbrle | http://www.xbrl.org/CR/2020-05-06/error |
The prefix dtr-type
denotes any namespace that is the namespace for a type defined in the Data Types Registry [DTR STRUCTURE].
This specification defines two classes of processors:
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.
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]).
The top-level component is a report.
An optional URL recording the location from which the report was loaded (or an explicitly specified alternative base URL). 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.
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.
A unique identifier for the fact. The value MUST be an NCName (xbrle:invalidFactId), and MUST be unique across all facts within the report (xbrle:duplicateFactId). This property MUST be present on all facts (xbrle: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.
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 datatype (xbrle:invalidFactValue).
The {decimals} property MUST be present on, and MUST only be present on, numeric facts (xbrle:misplacedDecimalsProperty).
A fact's datatype is the XML Schema type of the concept identified by the fact's concept core dimension.
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
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.
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] .
xbrl:concept
The concept core dimension MUST be present on all facts (xbrle:missingConceptDimension).
The concept core dimension MUST identify a concept from the taxonomy (xbrle:unknownConcept).
The identified concept MUST NOT be abstract (xbrle:valueForAbstractConcept).
xbrl:entity
The entity core dimension MUST NOT have a scheme of 'http://www.xbrl.org/CR/2020-05-06/entities
' with an identifier of 'NA
'.
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 'http://www.xbrl.org/CR/2020-05-06/entities
' and identifier 'NA'
is used to represent the absence of this dimension in xBRL-XML syntax.
xbrl:period
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.
If the fact's period type is duration
, the period code dimension is optional, and if present {interval} MUST be a non-zero length time interval (xbrle:invalidPeriodDimension).
If the fact's period type is instant
, the period code dimension MUST be present (xbrle:missingPeriodDimension) and {interval} MUST be a zero-length time interval (xbrle: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
.
xbrl:unit
The unit core dimension MUST only be present on numeric facts (xbrle: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 (xbrle: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]).
xbrl:language
The language core dimension MUST only be present on text facts (xbrle:misplacedLanguageDimension) and is optional on such facts.
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).
The {id} property MUST be the same as the fact's {id} property (xbrle:invalidNoteIDValue).
This dimension MUST NOT be present on facts with a concept core dimension that is not xbrl:note
(xbrle:misplacedNoteIDDimension).
See also Section 3.5.1.1.
The {name} of a taxonomy-defined dimension MUST identify a dimension in the taxonomy (xbrle:unknownDimension).
If the identified dimension is an explicit dimension, the {value} MUST be a valid expanded name; otherwise, if {value} is the special value "nil", the typed dimension MUST be nillable; otherwise, {value} MUST be in the value space for the datatype of the typed dimension (xbrle:invalidDimensionValue).
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.
Links represent relationships between facts in a report. Links are a generalisation of the footnote mechanism defined in XBRL v2.1.
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
(xbrle:illegalStandardFootnoteTarget).
The mapping between links and footnotes as defined in XBRL v2.1 is described in xBRL-XML [xBRL-XML].
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 (xbrle: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 (xbrle: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
:
Note that as text facts, xbrl:note
facts cannot have the {decimals} property or unit core dimension.
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
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.
Two reports, A and B, are equal under this model if:
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 dimension values are equal if they meet the relevant criterion defined below:
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.
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:
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.
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).
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 |
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 06 May 2020. 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.