XBRL Core Taxonomy Information 1.0

Public Working Draft 17 May 2023

This version
https://www.xbrl.org/Specification/cti/PWD-2023-05-17/cti-PWD-2023-05-17.html
Editors
Mark Goodhand, CoreFiling <mrg@corefiling.com>
Paul Warren, XBRL International Inc. <pdw@xbrl.org>

Table of Contents

Definitions

Error codes

1 Introduction

XBRL taxonomies provide more than a simple dictionary of reporting concepts and dimensions. Taxonomies typically include labels in multiple languages, references to authoritative documentation, calculation relationships, and structures to assist in the presentation and validation of XBRL reports.

For certain operations, however, the full set of taxonomy metadata is surplus to requirements, and performance and usability improvements can be achieved by focusing on a subset of taxonomy metadata.

This document defines an abstract model for the subset of taxonomy information that is essential for faithfully loading an xBRL-XML, xBRL-JSON or xBRL-CSV document into an OIM Report model. This subset is referred to as Core Taxonomy Information (CTI).

Whereas XBRL taxonomies have traditionally been serialised in XML form, using a combination of XML Schema and XLink, this specification defines a syntax-independent model along with an alternative JSON serialisation.

1.1 Documentation conventions

1.1.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. "MUST" or "MUST NOT" statements that do not have a prescribed error code are not automatically enforceable, and processors are not required to detect violations.

1.2 Namespaces and namespace prefixes

The JSON serialisation of the Core Taxonomy Information model makes use of QNames to represent expanded names. The prefix map for resolving QNames is provided by the namespaces object. Any prefixes used by QNames are resolved as described in OIM Common.

Prefixes used in this specification are to be interpreted according to the following table:

Prefix Namespace URI
dtr-type http://www.xbrl.org/dtr/type/*
xbrli http://www.xbrl.org/2003/instance
xs http://www.w3.org/2001/XMLSchema
enum2 http://xbrl.org/2020/extensible-enumerations-2.0
ctie https://xbrl.org/PWD/2023-05-17/cti/error
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 Type Registry.

2 Validation

When attempting to construct a CTI model from a DTS or a JSON document with the CTI document type, a CTI processor MUST raise errors with the specified error codes if the document does not conform to the constraints defined in this specification.

3 Core Taxonomy Information Model

The CTI model captures the minimum subset of taxonomy information required to faithfully load xBRL-XML, xBRL-JSON and xBRL-CSV documents into a report, enforcing the constraints expected for a conformant processor.

The CTI 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 sections shown below. Components may also have constraints associated with them which all instantiations of these components must adhere to.

3.1 Taxonomy Definition Component

The top-level component in the CTI model is a taxonomy definition component. It has the following properties:

{urls}
A list of taxonomy URLs used to identify the taxonomy
{concepts}
A set of concept definition components
{dimensions}
A set of dimension definition components
{types}
A set of type definition components

Constraints:

3.2 Concept Definition Component

The concept definition component provides the core information for a reporting concept. It has the following properties:

{name}
An expanded name that uniquely identifies the concept within this taxonomy.
{type}
An expanded name identifying the type of the concept.
{nillable}
Boolean value indicating whether the concept is nillable.
{periodType}
String value indicating whether the concept captures information for an instant in time (instant) or information applicable to a period of time (duration).
{abstract}
Boolean value indicating whether the concept is abstract.

Constraints:

The prefixed type signifies prefixed content other than QName, SQName and SQNames. OIM processors MAY choose to support specific types of additional prefixed content, but cannot support arbitrary formats as it is necessary to know the details of the format in order to be able to reliably identify the prefixes. As such, it is not meaningful to specify prefixed alone as the {type} for a concept definition component or dimension definition component; a named type definition component with a {builtInType} of prefixed MUST be used instead.

3.3 Dimension Definition Component

The dimension definition component provides the core information for a taxonomy-defined dimension . It has the following properties:

{name}
An expanded name that uniquely identifies the dimension within this taxonomy.
{type}
An expanded name identifying the type of the dimension.
{nillable}
Boolean value indicating whether the dimension is nillable.
{default}
Optional expanded name indicating the default member for the dimension.

Constraints:

XBRL Dimensions 1.0 distinguishes between "typed" and "explicit" dimensions, and associates additional report validation requirements with the latter. With the exception of the {default} property, these constraints are beyond the scope of the CTI model. CTI processors that attempt serialisation of CTI models to XML will have to account for the fact that default members only apply to explicit dimensions. Otherwise, this specification makes no use of the distinction. As noted in OIM, explicit dimensions will have a type of QName, but a type of QName does not imply that the dimension is explicit (it may be a QName typed dimension).

3.4 Type Definition Component

The type definition component links a custom type to its built-in type. It has the following properties:

{name}
An expanded name that uniquely identifies the type within this taxonomy.
{builtInType}
An xs:NCName identifying the built-in type this type is based on.

Constraints:

3.5 Built-in types

The following table enumerates the built-in types of the CTI model.

Each item type defined by the XBRL 2.1 specification and each built-in type defined by XML Schema has a corresponding CTI built-in type, though in some cases it is the special unsupported type.

builtInType concept schema type dimension schema type numeric? text? notes
float xbrli:floatItemType xs:float true false
double xbrli:doubleItemType xs:double true false
decimal xbrli:decimalItemType xs:decimal true false
integer xbrli:integerItemType xs:integer true false
negativeInteger xbrli:negativeIntegerItemType xs:negativeInteger true false
nonPositiveInteger xbrli:nonPositiveIntegerItemType xs:nonPositiveInteger true false
nonNegativeInteger xbrli:nonNegativeIntegerItemType xs:nonNegativeInteger true false
positiveInteger xbrli:positiveIntegerItemType xs:positiveInteger true false
long xbrli:longItemType xs:long true false
int xbrli:intItemType xs:int true false
short xbrli:shortItemType xs:short true false
byte xbrli:byteItemType xs:byte true false
unsignedLong xbrli:unsignedLongItemType xs:unsignedLong true false
unsignedInt xbrli:unsignedIntItemType xs:unsignedInt true false
unsignedShort xbrli:unsignedShortItemType xs:unsignedShort true false
unsignedByte xbrli:unsignedByteItemType xs:unsignedByte true false
date xbrli:dateItemType xs:date false false
time xbrli:timeItemType xs:time false false
dateTime dtr-type:dateTimeItemType xs:dateTime false false
dateUnion xbrli:dateTimeItemType xbrli:dateUnion false false allows xs:date or xs:dateTime
duration xbrli:durationItemType xs:duration false false
yearMonth xbrli:gYearMonthItemType xs:gYearMonth false false
year xbrli:gYearItemType xs:gYear false false
monthDay xbrli:gMonthDayItemType xs:gMonthDay false false
day xbrli:gDayItemType xs:gDay false false
month xbrli:gMonthItemType xs:gMonth false false
boolean xbrli:booleanItemType xs:boolean false false
base64Binary xbrli:base64BinaryItemType xs:base64Binary false false
hexBinary xbrli:hexBinaryItemType xs:hexBinary false false
URI xbrli:anyURIItemType xs:anyURI false false
string xbrli:stringItemType xs:string false true
normalizedString xbrli:normalizedStringItemType xs:normalizedString false true
token xbrli:tokenItemType xs:token false true
language xbrli:languageItemType xs:language false false
Name xbrli:NameItemType xs:Name false false
NCName xbrli:NCNameItemType xs:NCName false false
QName xbrli:QNameItemType xs:QName false false
SQName dtr-type:SQNameItemType dtr-type:SQNameType false false
SQNames dtr-type:SQNamesItemType dtr-type:SQNamesType false false
noLangToken dtr-type:noLangTokenItemType false false only for facts
noLangString dtr-type:noLangStringItemType false false only for facts
domainMember dtr-type:domainItemType false false only for facts
enumeration enum2:enumerationItemType false false only for facts
enumerationSet enum2:enumerationSetItemType false false only for facts
unsupported xbrli:fractionItemType, tuples xs:ENTITY, xs:ENTITIES, xs:ID, xs:IDREF, xs:IDREFS, xs:NMTOKEN, xs:NMTOKENS, xs:NOTATION, complex types, and types derived by list or union (except xbrli:dateUnion) for oime:unsupportedConceptDataType and oime:unsupportedDimensionDataType
prefixed dtr-type:prefixedContentItemType subtypes not covered above dtr-type:prefixedContentType subtypes not covered above oime:unsupportedConceptDataType or oime:unsupportedDimensionDataType if the OIM processor has no special handling for the named type

Note that the list above only includes types that have OIM significance.

Other derived types defined by the XBRL 2.1 specification (xbrli:monetaryItemType, xbrli:sharesItemType and xbrli:pureItemType) and in the Data Type Registry (e.g. dtr-type:massItemType, dtr-type:lengthItemType) are not built-in, and MUST therefore be included as named types in the CTI model whenever they are used by concepts.

The one exception is dtr-type:dateTimeItemType, which is included to ensure every supported XML Schema type is covered for both concepts and dimensions.

4 DTS serialisation

A Discoverable Taxonomy Set (DTS) is a collection of XML Schema documents and XLink linkbase documents that can be discovered from a given list of entry point URLs, according to the DTS discovery rules defined in XBRL 2.1

A CTI model may be loaded from, or serialised to, a DTS that is valid according to XBRL 2.1, XBRL Dimensions 1.0 and Extensible Enumerations 2.0.

A valid XML serialisation of a CTI model C is any XML serialisation that results in a model equivalent to C when reloaded according to the rules in this section.

Note that many features of the XML representation have no bearing on the CTI model, including

4.1 Entry point URL mapping

When a CTI model is built from a DTS, the {urls} property of the CTI model contains the URLs that were used as the starting point for DTS discovery.

When a DTS is constructed from a CTI model, for each URL U in the {urls} property a schema document is created at the location specified by U. Additional schema documents MAY be constructed as necessary to represent all of the namespaces in the CTI model.

4.2 Concept mapping

The CTI model contains a concept definition component CDC for each element declaration component XEDC in the DTS schemas that meets the following conditions:

The XBRL Dimensions specfication (XDT) uses concepts to represent hypercubes. According to the rules above, element declarations that are hypercubes (per XDT 1.0 section 2.2) will be included in the set of concept definition components, but these will never be usable as values for the concept core dimension. XDT section 2.2.1 requires processors to "raise an error (xbrldte:HypercubeElementIsNotAbstractError) if an element that is in the substitution group of the xbrldt:hypercubeItem element is not abstract". OIM gives no special significance to hypercubes, but any XDT-valid hypercube will have the value true for the {abstract} property, and hence be recognisable to non-validating OIM processors as unusable in reports as a value for the concept dimension (oime:valueForAbstractConcept).

The properties of CDC are as follows:

{name}
An expanded name of composed of the {target namespace} and {name} of XEDC.
{type}
The name of the appropriate built-in type (per Section 3.5) if XEDC's {type definition} is one of the built-in item types defined by XBRL 2.1 section 5.1.1.3. Otherwise, the full expanded name of XEDC's {type definition}`, which will correspond to a type definition component in the CTI model.
{nillable}
The value of the {nillable} property of XEDC.
{periodType}
the value of XEDC's periodType attribute, per XBRL 2.1 5.1.1.1, if present; otherwise, duration.
{abstract}
The value of the {abstract} property of XEDC.

XBRL 2.1 requires that "The @periodType attribute MUST be used on elements in the substitution group for the element" whereas "Tuple declarations in Taxonomy Schemas MUST NOT include a @periodType". Although tuples are not supported by OIM, the CTI includes concept definition components for tuples (with {type} unsupported) to enable conformant OIM processors to flag oime:unsupportedConceptDataType. Accordingly, the wording above allows for the absence of the periodType attribute.

4.3 Dimension mapping

The CTI model contains a dimension definition component DDC for each element declaration component XEDC in the DTS schemas that meets the following conditions:

If XEDC is a typed dimension, let XTD be the element declaration identified by the dimension's xbrldt:typedDomainRef attribute, and XTDT be XTD's {type definition}`.

The XBRL Dimensions specfication (XDT) uses concepts to represent dimensions. Dimensions are required to be abstract, according to XDT 2.5.1: "A dimensional processor MUST raise an error xbrldte:DimensionElementIsNotAbstractError if an element that is in the substitution group of xbrldt:dimensionItem is not abstract". Accordingly, any QName that identifies a dimension definition component is recognisable to non-validating OIM processors as unusable in reports as a value for the concept dimension (oime:valueForAbstractConcept).

The properties of DDC are as follows:

{name}
An expanded name of composed of the {target namespace} and {name} of XEDC.
{type}
QName if the dimension is an explicit dimension; otherwise, the name of the appropriate built-in type (per Section 3.5) of XTDT, or if there is not an exact match to a built-in type, the full expanded name of XTDT, which will correspond to a type definition component in the CTI model.
{nillable}
The value of the {nillable} property for XTD if the dimension is a typed dimension; otherwise,false.
{default}
absent if the dimension is a typed dimension; otherwise, the expanded name of the default member for the dimension, per XDT 1.0 section 2.7.1.

4.4 Type mapping

The CTI model contains a type definition component TDC for each type definition component XTDC in the DTS schemas that meets the following conditions:

The properties of TDC are as follows:

{name}
The name of XTDC, or in the case of anonymous types, a generated name that is unique in the context of the CTI.
{builtInType}
The name of the appropriate built-in type (per Section 3.5) discovered by traversing XTDC's Type Definition Hierarchy and selecting the most specific matching type (the furthest from the root ur-type definition).

5 JSON serialisation

This section defines a JSON serialisation of the CTI model. CTI models may be loaded from and serialised to this JSON representation as an alternative to the DTS serialisation.

5.1 JSON representation constraints

CTI JSON documents MUST be valid JSON, per RFC 8259 (ctie:invalidJSON).

In order to avoid interoperability issues, objects within JSON documents conforming to this specification MUST have unique keys (ctie:invalidJSON).

JSON documents MUST use the UTF-8 character encoding (ctie:invalidJSON), and MAY include a Unicode Byte Order Mark, although this is neither required nor recommended.

This specification documents the allowed types for all values in JSON metadata. Types are specified as a combination of JSON primitive types (string, array, object, number, boolean and null) and an optional XML Schema built-in simple type, identified by a QName. Values within JSON documents MUST have the JSON type specified and, where an XML Schema type is specified, MUST be in the canonical lexical representation for that type (ctie:invalidJSONStructure).

Properties marked as "required" MUST be present wherever the enclosing object is present (ctie:invalidJSONStructure).

5.2 Document type identification

A CTI JSON document is a JSON document with the CTI document type .

A document has the CTI document type if it is a valid JSON document in which the JSON Pointer /documentInfo/documentType resolves to the string https://xbrl.org/PWD/2023-05-17/cti. A document that does not have the CTI document type MUST be treated as described in OIM Common and the errors defined in this specification MUST NOT be raised, aside from ctie:invalidJSON (see Section 5.1).

5.3 Extensibility

In order to facilitate the inclusion of additional information within the metadata file, additional properties beyond those defined in this specification MAY be included within the following objects:

Any such additional properties included in the above objects MUST have names that are QName values (ctie:invalidJSONStructure), and unless defined in a specification published by XBRL International MUST have a prefix that identifies a namespace that does not use the xbrl.org domain name.

The content of any such additional properties is not constrained by this specification.

5.4 CTI JSON structure

A CTI JSON document consists of a JSON object with the following properties:

documentInfo (object)
(required) A documentInfo object.
taxonomy (object)
(optional) A taxonomy object.

5.4.1 documentInfo

The documentInfo object provides document-level information about the CTI model. The object has the following properties:

documentType (string)
(required) The fixed value https://xbrl.org/PWD/2023-05-17/cti
namespaces (object)
(optional) A namespaces object.

Additional properties are allowed, subject to the constraints in Section 5.3.

5.4.2 documentInfo/namespaces

The namespaces object is an object that provides the prefix map for QNames values within the JSON document. The content of the map MUST conform to the constraints defined in OIM Common for URI maps.

Each key provides a prefix, which is mapped to the URI provided by the value.

5.4.3 taxonomy

The taxonomy object contains JSON representations of the components in the CTI model. The object has the following properties:

concepts (object)
(optional) A concepts object.
dimensions (object)
(optional) A dimensions object.
types (object)
(optional) A types object.
urls (array)
(required) An array of URLs (xs:anyURI) identifying the taxonomy. Relative URLs are resolved relative to the file in which the property appears.

Additional properties are allowed, subject to the constraints in Section 5.3.

Processors MUST support http, https and file URLs. 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.

5.4.4 taxonomy/concepts

The concepts object contains concept objects, keyed by name.

Each key of the concepts object MUST be an xs:QName (ctie:invalidJSONStructure) corresponding to the {name} property of a concept definition component C.

Each value is concept object with the following properties:

type (string)
(required) An xs:QName representing the {type} property of C.
nillable (boolean)
(optional) A boolean value corresponding to the {nillable} property of C.
periodType (string)
(optional) A string value corresponding to the {periodType} property of C.
abstract (boolean)
(optional) A boolean value corresponding to the {abstract} property of C.

If any of the optional boolean properties above is omitted, the corresponding property of C has the value false.

If periodType is omitted, the corresponding property of C has the value duration.

5.4.5 taxonomy/dimensions

The dimensions object contains dimension objects, keyed by name.

Each key of the dimensions object MUST be an xs:QName (ctie:invalidJSONStructure) corresponding to the {name} property of a dimension definition component D.

Each value is dimension object with the following properties:

type (string)
(required) An xs:QName representing the {type} property of D.
nillable (boolean)
(optional) A boolean value corresponding to the {nillable} property of D.
default (string)
(optional) An xs:QName representing the {default} property of D.

If the nillable property of the dimension object is omitted, the corresponding property of D has the value false.

5.4.6 taxonomy/types

The types object contains type objects, keyed by name.

Each key of the types object MUST be an xs:QName (ctie:invalidJSONStructure) corresponding to the {name} property of a type definition component T.

Each value is type object with the following properties:

builtInType (string)
(required) An xs:NCName representing the {builtInType} property of T.

5.4.7 Example

{
    "documentInfo": {
        "documentType": "https://xbrl.org/PWD/2023-05-17/cti",
        "namespaces": {
            "ark": "https://example.com/ark/2021",
            "arkm": "https://example.com/ark-materials/2021",
            "dtr": "http://www.xbrl.org/dtr/type/2020-01-21",
            "xbrli": "http://www.xbrl.org/2003/instance"
        }
    },
    "taxonomy": {
        "concepts": {
            "ark:AnimalName": {
                "abstract": false,
                "nillable": false,
                "periodType": "duration",
                "type": "ark:textWithLang"
            },
            "ark:AnimalWeight": {
                "type": "dtr:massItemType"
            },
            "ark:CostOfMaterials": {
                "type": "xbrli:monetaryItemType"
            },
            "ark:HoursSpentBuildingTheArk": {
                "type": "decimal"
            },
            "ark:NumberOfAnimalsOnArk": {
                "type": "ark:evenPositiveIntegerItemType"
            },
            "ark:PercentageComplete": {
                "periodType": "instant",
                "type": "dtr:percentItemType"
            },
            "arkm:All": {
                "type": "domainMember",
                "abstract": true
            },
            "arkm:Canvas": {
                "type": "domainMember",
                "abstract": true
            },
            "arkm:Nails": {
                "type": "domainMember",
                "abstract": true
            },
            "arkm:Wood": {
                "type": "domainMember",
                "abstract": true
            }
        },
        "dimensions": {
            "ark:AnimalId": {
                "type": "token"
            },
            "ark:MaterialType": {
                "default": "arkm:AllMaterials",
                "type": "QName"
            }
        },
        "types": {
            "ark:evenPositiveIntegerItemType": {
                "builtInType": "positiveInteger"
            },
            "ark:textWithLang": {
                "builtInType": "string"
            },
            "dtr:massItemType": {
                "builtInType": "decimal"
            },
            "dtr:percentItemType": {
                "builtInType": "decimal"
            },
            "xbrli:monetaryItemType": {
                "builtInType": "decimal"
            }
        },
        "urls": [
            "https://example.com/arkTaxonomy/2021/ark.xsd"
        ]
    }
}

Appendix A 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 (https://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 (https://www.xbrl.org/legal).