Data Type Registry - Structure 1.1

Public Working Draft 11 October 2017

Copyright © 2017 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/dtr-structure-1.1/PWD-2017-10-11/dtr-structure-1.1-PWD-2017-10-11.html>
Editor:
Paul Warren, XBRL International Inc. <pdw@xbrl.org>
Contributors:
Mark Goodhand, CoreFiling <mrg@corefiling.com>
Hugh Wallis, Formerly of XBRL International Inc.

Status

Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to dtram@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document describes the structure of the XBRL International Data Type Registry. The Data Type Registry is an online listing of data types that have been identified as potentially having wide utility. The Registry contains structured information about their purpose, usage and any intended impact on XBRL instance validation.

Comment

1 Paul Warren: Re-using the 2009 version of <dtr:type> is problematic here as all elements are required. I don't think we want to change the namespace of the published DTR, so I think we either need to create a new schema defining a suitable element, or a new element within the existing schema (e.g. <dtr:typeAnnotation> ), using a cheeky in place edit (although as we're the only people publishing a document that conforms to the schema, I don't see that as an issue.)

Table of Contents

1 Goals
1.1 Relationship to other work
1.2 Terminology
1.3 Language
1.4 Document conventions
1.4.1 Typographic conventions
1.4.1.1 Definition notation
1.4.1.2 Footnote notation
1.4.1.3 Element and attribute notation
1.4.2 Formatting conventions
2 Namespaces and namespace prefixes
3 Data Model
4 Schema definitions
4.1 Schema versions
5 Hosting on the XBRL.org website
6 Status of Data Types in the DTR and Implications for Software

Appendices

A Schema
A.1 dtr.xsd
B Sample dtr document (non-normative)
C References
D Intellectual property status (non-normative)
E Acknowledgements (non-normative)
F Document history (non-normative)
G Errata corrections in this document

Tables

1 Namespaces and namespace prefixes
2 A DTR entry
3 Schema annotations

Definitions

abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor and any other terms not specifically defined elsewhere in this document but which are used and defined in the XBRL 2.1 specification.
DTR index
Publication URL


1 Goals

XBRL provides a set of standard data types that may appear in XBRL instances. These include those specified in [XBRL 2.1]. As XBRL applications emerge, new, non-standard data types having common and useful semantics are being proposed. The goal of the XBRL Data Type Registry (hereinafter "DTR") is to be a public, online data set that documents these non-standard data types and their usage. Additions and other changes to the DTR, like other XBRL International work products, will proceed through a series of steps whose goal is to maximise the utility and longevity of the new data types and the instances that use them. This process is documented in [DTR PROCESS 1.1].

1.1 Relationship to other work

This document describes a backwards-compatible revision of DTR Structure 1.0 [DTR STRUCTURE]. The format of the registry itself remains unchanged, but the information contained in it is now generated from structured metadata contained with the schema definitions for the types.

This document pertains to XBRL as defined in the XBRL Specification [XBRL 2.1].

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

abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor and any other terms not specifically defined elsewhere in this document but which are used and defined in the XBRL 2.1 specification. are as defined by [XBRL 2.1] .

1.3 Language

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

All documentation supporting a registry entry MUST be provided in English, and MAY be provided in additional languages.

1.4 Document conventions

1.4.1 Typographic conventions

1.4.1.1 Definition notation

Definitions are highlighted with green text.

1.4.1.2 Footnote notation

Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.

1.4.1.3 Element and attribute notation

When referring to a specific element, it will be identified by its namespace prefix and local name. For example, the root element of a versioning report would be referred to as <ver:report> .

Attributes are also identified by their local name and, where appropriate, their namespace prefix. Attributes are distinguished from elements by prefixing them by an @ symbol. Thus, @id refers to the attribute with the name id.

When referring to any attribute, so long as it has a specific namespace, the local name is replaced by an asterisk ( *). Thus, the notation @xml:* specifies any attribute in the namespace http://www.w3.org/XML/1998/namespace.

1.4.2 Formatting conventions

The following highlighting is used for normative technical material in this document:

Text of the normative example.

The following highlighting is used for non-normative examples in this document:

Text of the non-normative example.

The following highlighting is used for non-normative examples of poor, discouraged or disallowed usage.

Text of the discouraged example.

2 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 is 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 http://www.xbrl.org/2009/dtr
xsd http://www.w3.org/2001/XMLSchema

3 Data Model

The data model of the DTR is a list of each data type definition augmented with additional indicators and information needed by developers. This information has a standard XML format referred to as the DTR index. The DTR index on the xbrl.org website, as described in Section 5.

The information in the data model is obtained the schema definitions for the types, as described in Section 4

Table 2: A DTR entry
Field Type Explanation Example
Data Type Namespace anyURI This is the namespace of the data type being defined.
http://www.xbrl.org/dtr/type/2017-07-04
Data Type Name NCName This is the local name of the data type being defined.

A data type in the registry MUST NOT have the same Data Type Name as any other type in the registry.

A data type in the registry MUST NOT have different semantics to a data type with the same Data Type Name that has been published at REC status in an earlier version of the register. If different semantics are required, a different Data Type Name should be used.

domainItemType
Status {CR, REC, PROPOSED, RR} The XBRL International status of this data type.
  • CR - Candidate Recommendation. A public draft of a new datatype.
  • REC - Recommendation
  • PROPOSED - Submitted but with no official status yet granted by XBRL International. This status is not used in published versions of the registry.
  • RR - Rescinded Recommendation. This status is not used in published versions of the registry
CR
Authoritative Location anyURI URI of fragment in a schema where the definition resides.
http://www.xbrl.org/dtr/type/2017-07-04.xsd#domainItemType
Version Date date Effective date of this version of the data type; all versions of the same data type with earlier dates are effectively superseded.
2017-07-04
Requirements XHTML mixed A statement of the requirements that gave rise to this data type. Requirements in different languages are distinguished using the @xml:lang attribute and an ISO 639 language code [ISO].
Requested by major taxonomy project
Definition XHTML mixed The meaning of the data type described in the same way as if it were part of an XBRL Specification. Definitions in different languages are distinguished using the @xml:lang attribute and an ISO 639 language code [ISO] .
The domain member item type indicates that an element is a domain member.
Version of XBRL token The XBRL version for which this an extension. Note that a data type could be "promoted" into a standard data type in some future version of the specification.
2.1
Minimum Edition Date date The XBRL edition date and beyond for which this is an extension.
2003-12-31

4 Schema definitions

Definitions of types within the registry MUST include annotations in the schema, as described in this section. These annotations are included in an <xsd:annotation> element within the schema definition, and are used to populate the DTR. The table below documents the allowed elements, and their mapping to items in the data model Section 3.

[Paul Warren: Re-using the 2009 version of <dtr:type> is problematic here as all elements are required. I don't think we want to change the namespace of the published DTR, so I think we either need to create a new schema defining a suitable element, or a new element within the existing schema (e.g. <dtr:typeAnnotation> ), using a cheeky in place edit (although as we're the only people publishing a document that conforms to the schema, I don't see that as an issue.) ]
Table 3: Schema annotations
Element Data model mapping Notes
xsd:documentation Definition This element MAY be repeated in different languages
xsd:appinfo/dtr:type/dtr:status Status
xsd:appinfo/dtr:type/dtr:requirement Requirement This element MAY be repeated in different languages

4.1 Schema versions

With the exception of the initial release noted below, all data types within a given release of the registry MUST be contained within a single XML Schema, targetting a namespace that uniquely identifies the status and release date of the registry.

Earlier releases of the registry conforming to DTR Structure 1.0 [DTR STRUCTURE] and DTR Process 1.0 [DTR PROCESS] were split into multiple schemas, and used an unversioned namespace. The latest version of the registry under version 1.0 of these specifications is adopted as the initial version under this 1.1 specification, and is an exception to the requirement stated above.

5 Hosting on the XBRL.org website

The latest DTR index from the REC DTR release will be placed at a fixed location on the xbrl.org website and will be the file at the URL http://www.xbrl.org/dtr/dtr.xml. Each release will also be permanently archived in a subdirectory whose name contains the date on which it became effective (e.g. http://www.xbrl.org/dtr/2009-01-22/dtr.xml).

6 Status of Data Types in the DTR and Implications for Software

Software vendors are NOT obliged to implement support for any REC data type in order to continue to claim that they support the base specification.

Under DTR Process v1.1 [DTR PROCESS 1.1], changes to the DTR are grouped into public releases. This avoids having multiple versions of the same schema with different content, and is intended to ease the definition of conformance levels, as users can assert or require conformance with a particular release version, rather than a list of individual data types.

Appendix A Schema

This section contains XML files that form part of this specification. Each document has a standard Publication URL, at which the normative copy of the document is published. A non-normative copy of each document is included in this appendix for convenience.

All references to these documents made for the purposes of DTS Discovery MUST resolve to the Publication URL, after applying XML Base processing (where applicable) and resolving any relative URLs.

It should be noted that the path component of a URL is case-sensitive, and so must match exactly. Further, alternative hosts and schemes that happen to resolve to the same location are not considered equivalent and may not be used. See [URI] for more details on URL equivalence.

The requirement to reference documents by Publication URL does not prevent processors from substituting local copies of the documents for performance or other reasons.

A.1 dtr.xsd

The following is the XML schema corresponding to the data model described in Section 3.

The Publication URL for this schema is http://www.xbrl.org/dtr/dtr.xsd.

<!-- (c) 2005-2010 XBRL International. All Rights Reserved. http://www.XBRL.org/legal/ This document 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. XBRL(r), is a trademark or service mark of XBRL International, Inc., registered in the United States and in other countries. -->
<xs:schema
  xmlns:xs
="http://www.w3.org/2001/XMLSchema"

  xmlns:dtr
="http://www.xbrl.org/2009/dtr"
targetNamespace="http://www.xbrl.org/2009/dtr" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="DocumentationType" mixed="true">
<xs:annotation>
<xs:documentation>
Definition of a type to contain mixed text and XHTML markup
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:any namespace="http://www.w3.org/1999/xhtml" processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:group name="typeGroup">
<xs:sequence>
<xs:element ref="dtr:typeNamespace"/>
<xs:element ref="dtr:typeName"/>
<xs:element ref="dtr:status"/>
<xs:element ref="dtr:versionDate"/>
<xs:element ref="dtr:authoritativeHref"/>
<xs:element ref="dtr:requirement" maxOccurs="unbounded"/>
<xs:element ref="dtr:definition" maxOccurs="unbounded"/>
<xs:element ref="dtr:versionOfXBRL"/>
<xs:element ref="dtr:minimumEditionDate"/>
</xs:sequence>
</xs:group>
<xs:element name="dtr">
<xs:annotation>
<xs:documentation>
Root element of the XBRL Data Type Registry
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="types">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="type">
<xs:complexType>
<xs:group ref="dtr:typeGroup"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="version" type="xs:token" fixed="1.0"/>
</xs:complexType>
</xs:element>
<xs:element name="typeNamespace" type="xs:anyURI">
<xs:annotation>
<xs:documentation>
This is the namespace for type being defined.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="typeName" type="xs:NCName">
<xs:annotation>
<xs:documentation>
This is the local name of the type being defined.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="status">
<xs:annotation>
<xs:documentation>
The XBRL International status of this type. CR, REC, NIE, PROPOSED, ACK or RR.
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="CR"/>
<xs:enumeration value="REC"/>
<xs:enumeration value="NIE"/>
<xs:enumeration value="PROPOSED"/>
<xs:enumeration value="ACK"/>
<xs:enumeration value="RR"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="versionDate" type="xs:date">
<xs:annotation>
<xs:documentation>
Effective date of this version of the type; all versions of the same type with earlier dates are effectively superseded
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="versionOfXBRL" type="xs:token">
<xs:annotation>
<xs:documentation>
The XBRL version for which this is an extension. In principle, a type could be "promoted" into a standard type in some future version of the specification.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="minimumEditionDate" type="xs:date">
<xs:annotation>
<xs:documentation>
The XBRL edition date and beyond for which this is an extension.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="requirement" type="dtr:DocumentationType">
<xs:annotation>
<xs:documentation>
A statement of the requirements that gave rise to this type. Requirements in different languages are distinguished using the xml:lang attribute.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="definition" type="dtr:DocumentationType">
<xs:annotation>
<xs:documentation>
The meaning of the type described in the same way as if it were in the Specification. Definitions in different languages are distinguished using the xml:lang attribute.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="authoritativeHref">
<xs:annotation>
<xs:documentation>
The absolute URI where the schema definition of the type is found.
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:anyURI">
<xs:pattern value=".*#.*"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>

Appendix B Sample dtr document (non-normative)

The following is an example of a dtr (as defined by the schema in Appendix A above). It contains only a single entry to illustrate the definition of a data type.

    <?xml version="1.0" encoding="UTF-8"?>
   
<dtr
  xmlns:xsi
="http://www.w3.org/2001/XMLSchema-instance"

  xmlns
="http://www.xbrl.org/2009/dtr"
version="1.0" xsi:schemaLocation="http://www.xbrl.org/2009/dtr dtr.xsd">
<types>
<type>
<typeNamespace>
http://www.xbrl.org/dtr/type/${VERSION}
</typeNamespace>
<typeName>
escapedItemType
</typeName>
<status>
REC
</status>
<versionDate>
2017-10-11
</versionDate>
<authoritativeHref>
https://www.xbrl.org/dtr/type/${VERSION}/types.xsd#escapedItemType
</authoritativeHref>
<requirement>
Interoperable Taxonomy Architecture (ITA) initiative requirement for alignment of the EDINET, IFRS and US GAAP taxonomies.
</requirement>
<definition xml:lang="en">
escapedItemType specializes string. There is no constraint on whether the resulting unescaped content is well-formed or not; this base type is exists so that processors know what to do with the content. It is a suitable base type for a data type whose unescaped content must be valid HTML 4.0 (which is not XML).
</definition>
<versionOfXBRL>
2.1
</versionOfXBRL>
<minimumEditionDate>
2003-12-31
</minimumEditionDate>
</type>
</types>
</dtr>

Appendix C References

DTR PROCESS
XBRL International Inc.. "Data Type Registry - Process 1.0"
Hugh Wallis.

(See http://www.xbrl.org/Specification/dtr/REC-2011-02-22/dtr-process-REC-2011-02-22.html)
DTR PROCESS 1.1
XBRL International Inc.. "Data Type Registry - Process 1.1"
Paul Warren.

(See http://www.xbrl.org/Specification/dtr/REC-2011-02-22/dtr-process-REC-2011-02-22.html)
DTR STRUCTURE
XBRL International Inc. "Data Types Registry - Structure 1.0"
Hugh Wallis.

(See http://www.xbrl.org/Specification/dtr/REC-2011-02-22/dtr-REC-2011-02-22.html)
IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.

(See http://www.ietf.org/rfc/rfc2119.txt)
ISO
International Standards Organisation. " ISO 4217 Currency codes, ISO 639 Language codes, ISO 3166 Country codes, ISO 8601 international standard numeric date and time representations. "
(See http://www.iso.ch/)
URI
IETF (Internet Engineering Task Force). "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"
T. Berners-Lee
, L. Masinter, and R. Fielding.
(See http://tools.ietf.org/html/rfc3986)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2013-02-20"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html)
XML Names
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Third Edition)"
(See http://www.w3.org/TR/2009/REC-xml-names-20091208)

Appendix D 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 (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).

Appendix E Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix F Document history (non-normative)

DateAuthorDetails
04 July 2017Paul Warren

v1.1, prescribing the format of schema type definitions.

11 October 2017Paul Warren

Initial PWD of v1.1

Appendix G Errata corrections in this document

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 Link Role Registry Approval Manager up to and including 11 October 2017. 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.