Open Information Model Common Definitions 1.0

Candidate Recommendation 12 June 2019

Copyright © XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/oim-common/CR-2019-06-12/oim-common-CR-2019-06-12.html>
Editors:
Paul Warren, XBRL International Inc. <pdw@xbrl.org>
Herm Fischer, Mark V Systems Limited <fischer@markv.com>
Mark Goodhand, CoreFiling <mrg@corefiling.com>

Status

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.

Abstract

This document provides a set of common definitions used concrete representations of the XBRL Open Information Model.

Table of Contents

1 Introduction
1.1 Terminology
1.2 Namespaces and namespace prefixes
2 Definitions
2.1 SQName
2.2 Prefix map
2.3 URI map
2.4 Unit string representation

Appendices

A References
B Intellectual property status (non-normative)
C Document History (non-normative)
D Errata Corrections incorporated in this document

Table

1 Namespaces and namespace prefixes

Example

1 Examples of standard string representation of units

Definitions


Lexicograhic order
Prefix Map
Reserved prefix
SQName
URI Map

Error codes

oimce:invalidEmptyURIAlias
oimce:invalidPrefixForURIWithReservedAlias
oimce:invalidSQNamePrefix
oimce:invalidURIForReservedAlias
oimce:multipleAliasesForURI
oimce:multipleURIsForAlias
oimce:unboundSQNamePrefix


1 Introduction

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.

1.1 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 expanded name, NCName and QName are to be interpreted as described in the XML Names specification [XML Names].

The keywords Unit Core Aspect are to be interpreted as described in the Open Information Model [OIM].

1.2 Namespaces and namespace prefixes

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.

Table 1: Namespaces and namespace prefixes
Prefix Namespace URI
xbrl http://www.xbrl.org/CR/2019-06-12
xbrli http://www.xbrl.org/2003/instance
xsd http://www.w3.org/2001/XMLSchema
oimcehttp://www.xbrl.org/CR/2019-06-12/oim-common/error

2 Definitions

2.1 SQName

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

An SQName is a compact, colon-separated represention of a URI/value pair, where a short, document-scoped, prefix is used to represent the URI.

An SQName has the following format:

prefix:localname

The prefix MUST be a valid NCName (oimce:invalidSQNamePrefix) and MUST correspond to a key in the prefix map (oimce:unboundSQNamePrefix), and the namespace URI for identifier is taken from the corresponding value in the map.

Unlike QNames, the localname may be any string, including those containing the colon (":") character; the prefix and localname in an SQName are separated by the first colon character. Where an SQName is used to represent an expanded name, the localname will be a valid NCName.

2.2 Prefix map

A prefix map is a URI map that is used to resolve the prefix component of a QName or SQName to a URI.

A reserved prefix is a reserved URI alias that is specified as applying to a prefix map.

2.3 URI map

A URI map is a set of key/value pairs that is used to resolve the URI alias to full URIs. 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:

  1. The empty string MUST NOT be used as a URI alias (oimce:invalidEmptyURIAlias).
  2. A URI MUST NOT be bound to more than one URI alias within the map (oimce:multipleAliasesForURI).
  3. A URI aliasMUST NOT be bound to more than one URI within the map (oimce:multipleURIsForAlias).
  4. A reserved URI alias MUST only be bound to the URI prescribed for that URI alias (oimce:invalidURIForReservedAlias).
  5. A URI for which a reserved URI alias is prescribed MUST NOT be bound to any other URI alias (oimce:invalidPrefixForURIWithReservedAlias).

A reserved URI alias is any URI alias identified as being reserved by either this specification (see Section 1.2) or the specification defining the inclusion of the URI map.

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.

2.4 Unit string representation

The Unit Core Aspect defines units in terms of the combination of QNames by defining a list of numerators and a list 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 string representation for units, allowing units to be captured using a single, simple string value. This has the property that, provided that a consistent set of namespace prefixes are used, a given unit will have the single representation meaning that equivalence of units can be determined by a simple string comparison.

This representation is obtained as follows:

  1. If {denominators} is not present, the SQNames representing the {numerators} are combined in lexicographic order, separated by the "*" character.
  2. Otherwise, lists of {numerators} and {denominators} are created by combining SQNames in lexicographic order and separating with the "*" character, as above. If a list contains more than one item, the list is enclosed in parentheses, "(" and ")". The final string is then obtained by concatenating the list of numerators, the "/" character, and the list of denominators.

Whitespace is not permitted anywhere in the string representation, and the use of SQNames 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.

Lexicograhic order means ordered based on comparison of Unicode code point values of each character.

Example 1: Examples of standard string representation of units

The following list show a set of valid unit string representations.

  • iso4217:EUR
  • iso4217:EUR/xbrli:shares
  • utr:m*utr:m
  • utr:kg/(utr:m*utr:m)
  • (utr:m*utr:m*utr:m)/utr:S

Appendix A References

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)
OIM
XBRL International Inc.. "XBRL Open Information Model"
Paul Warren.

(See https://specifications.xbrl.org/release-history-open-information-model-oim.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 B 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 C Document History (non-normative)

DateAuthorDetails
14 December 2016Paul Warren

Candidate Recommendation. The contents of this specification were previously included in Public Working Drafts of the xBRL-JSON and OIM specifications.

02 May 2017Paul Warren

Second Candidate Recommendation

12 December 2018Paul Warren

Third Candidate Recommendation

12 June 2019Paul Warren

Fourth Candidate Recommendation

Appendix D Errata Corrections incorporated 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 Specification Maintenance Working Group (SWG) up to and including 12 June 2019. 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.