Copyright © XBRL International Inc., All Rights Reserved.
Circulation of this Recommendation is unrestricted. This document is normative. Recipients are invited to submit comments to email@example.com, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
1.2 Namespaces and namespace prefixes
2 Document types
3.2 Prefix map
3.3 URI map
3.4 Unit string representation
3.5 Period string representation
3.6 Space-separated list
The XBRL Open Information Model provides a syntax-independent definition of the content of an XBRL report. A number of alternative syntaxes are defined as concrete representations of the model. In order to achieve consistency between these representations, this document provides a number of definitions which may be used across these different formats.
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 expanded name, NCName and QName are to be interpreted as described in the XML Names specification [XML Names].
Many values in the Open Information Model are XML expanded
names, that is, the combination of a namespace URI and a localname.
This specification uses QName notation in the form
prefix:localname to refer to these, where the prefix
is a short string representing a full namespace URI. The prefixes used by this
specification are defined below. These prefixes are reserved prefixes.
This specification also uses the following prefix for error codes. This prefix is not a reserved prefix.
Most syntactic representations of the Open Information Model contain a "document type" string that identifies which specification and version the document conforms to. Processors MAY support multiple specificatons and versions. Processors MUST raise oimce:unsupportedDocumentType (or an equivalent code from a later version of this specification) if they encounter a document type that does not correspond to a specification that is supported by that processor, or if a document type is not present in the document.
The Open Information Model makes extensive use of expanded names ([XML Names]) to provide globally unique identifiers. These are a namespace URI/localname pair. In order to reduce size and improve readability, it is convenient to use a QName-like mechanism for representing these (and some other) values, where the globally unique namespace-URI is replaced with a compact, document-scoped prefix. The mechanism used is referred to as an SQName ("Simplified QName").
Where prefix is an NCName and localname is any string. The prefix is resolved to a URI using the prefix map.
Unlike QNames, the localname can consist of any non-whitespace characters, including colon (":"); the prefix and localname in an SQName are separated by the first colon character.
A prefix map is a URI map that is used to resolve the prefix component of a QName or SQName to a URI.
A URI map is a set of key/value pairs that is used to resolve URI aliases to full URIs. A URI alias is an NCName used to provide a limited scope short name for a URI. The location and format of a URI map is defined by the specification for the representation in which it is used, but it MUST conform to the following constraints:
This specification uses the term URI to refer to a value that conforms to the
xs:anyURI datatype [XML Schema Datatypes]. Such a value can be transformed into a value that conforms with the [RFC2396]/[RFC2732] definition of a URI reference by applying the URI reference escaping procedure described in [XML Schema Datatypes]. This specification uses the term encoded URI to refer to the result of this applying the URI reference escaping procedure.
xs:anyURIdatatype [XML Schema Datatypes], and the encoded URI MUST be an absolute URI Reference [RFC2396]/[RFC2732] (oimce:invalidURI).
URIs in this specification are used purely as unique identifiers, and should be compared using simple, case-sensitive string comparison. Percent-encoded characters are not considered equivalent to literal, unencoded characters.
It should be noted that some of the constraints listed above, such as the requirement for URI aliases to be unique within the map, may be enforced by syntactic or structural constraints of the format in which the map is represented. In this case, implementations should raise the appropriate error for that format, rather than the code listed above.
The unit core dimension defines units in terms of the combination of QNames by defining an unordered collection of numerators and an unordered collection of denominators. Reflecting this in concrete representations can be somewhat cumbersome, particularly as analysis the structure of units is expected to be a relatively uncommon operation compared to simply comparing units for equivalence, or rendering them to a user.
This section defines a standardised unit string representation, allowing units to be captured using a unique string value. This has the property that, provided that a consistent set of namespace prefixes are used, a given unit will have a single representation meaning that equivalence of units can be determined by string comparison.
The unit string representation is obtained as follows:
Whitespace is not permitted anywhere in the string representation, and the use of QNames ensures that a 1:1 mapping between prefixes and namespaces is available thus ensuring that equivalent units appearing within the same document are represented with the same string.
Processors MUST raise oimce:invalidUnitStringRepresentation if they encounter a unit string representation that does not conform to the syntax described above. If any QNames in the unit string representation use a prefix that is not defined in the prefix map then oimce:unboundPrefix MUST be raised.
The following list show a set of valid unit string representations.
The period core dimension takes a value that is a time interval, which may be zero-length (i.e. an instant). This section defines a standard period string representation which can be used to express such values.
The period string representation is obtained as follows:
The date-time values used in this representation MUST be valid according to the
xs:dateTime datatype and MUST be in the canonical lexical representation.
The error code oimce:invalidPeriodRepresentation MUST be raised for values that are required to be a period string representation and which do not conform to the above format.
It should be noted that unlike the
xbrli:dateUnion type used in xBRL-XML, the
xs:dateTime datatype used here does not allow the time component to be omitted.
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).
|14 December 2016||Paul Warren||
Candidate Recommendation. The contents of this specification were previously included in Public Working Drafts of the xBRL-JSON and OIM specifications.
|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
|14 October 2020||Paul Warren||
Sixth Candidate Recommendation
|03 February 2021||Paul Warren||
Seventh Candidate Recommendation
|07 July 2021||Paul Warren||
Eighth Candidate Recommendation
|04 August 2021||Paul Warren||
|13 October 2021||Paul Warren||
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 19 April 2023. 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.