1 Introduction

The XBRL v2.1 [XBRL 2.1] and XBRL Dimensions v1.0 [DIMENSIONS] specifications define an XML-based syntax for business reports, and accompanying meta-data definitions known as taxonomies. It is becoming increasingly appealing to work with XBRL data in a variety of different format 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 inconsistency 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.

1.1 Scope

This document provides a model for an XBRL report (or XBRL instance). It does not attempt to model the meta-data 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.

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

The keywords concept, context, DTS, fact footnote resource and XBRL instance are to be interpreted as described in the XBRL specification [XBRL 2.1].

The keywords dimension, hypercube, typed dimension and explicit dimension are to be interpreted as described in the XBRL Dimensions specification [DIMENSIONS].

1.3 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 are 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
oim	http://www.xbrl.org/PWD/2016-01-13/oim
xsd	http://www.w3.org/2001/XMLSchema

2 Assumptions

In order to achieve a simplified, logical view of XBRL data, the OIM only supports a subset of the functionality available in the XBRL v2.1 and related specifications.

The OIM only supports documents that conform to assumptions listed below. OIM Processors MUST raise an error when consuming a document if any of these assumptions are not satisfied.

2.1 Non-dimensional segment/scenario content

The <xbrli:segment> and <xbrli:scenario> elements MUST only contain <xbrldi:explicitMember> and <xbrldi:typedMember> elements.

2.2 Mixing segment and scenario elements

All hypercubes within the DTS of a report MUST be defined for use on the same container (either "segment" or "scenario"). The container that is not used for dimensions MUST be empty in all contexts in the XBRL instance.

2.3 Complex-typed dimensions

The XBRL instance MUST NOT make use of any typed dimensions that have a complex type.

2.4 Use of fractionItemType

The XBRL instance MUST NOT make use of any concepts with a type of, or derived from, xbrli:fractionItemType

2.5 Use of non-standard footnote resource roles

The XBRL instance MUST NOT contain any footnote resources with a role other than http://www.xbrl.org/2003/role/footnote. Footnote resources MAY be present with an unspecified role.

3 XBRL Report Model (non-GL)

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 top-level component is a report

This model is not intended to support reports that use XBRL GL [GLOBALLEDGER]. Whilst XBRL GL reports can be represented in the XBRL v2.1 XML syntax, the manner in which the syntax is used is different, and so is best captured in a separate model which will be added in future drafts of this specification.

Component: Report

Properties:

{DTS references}

A set of DTS references

{facts}

An unordered list of simple facts and tuple facts.

Abstract Component: Fact

A fact is a discrete piece of information in an XBRL Report. A fact is either a simple fact or a tuple fact. All facts have the following common properties.

Properties:

{id}

An optional unique identifier for the fact. The value must be an NCName, and must be unique across all simple facts and tuple facts within the report.

{aspects}

A set of aspects. The set may contain at most one of each core aspect. The set may contain multiple taxonomy defined aspects, but their {name} properties must be unique within the set.

{footnotes}

A list of footnotes associated with the fact. The ordering between footnotes with same {footnote type} and {footnote group} is significant and MUST be preserved. The ordering between footnotes with different {footnote type} or {footnote group} is not significant.

Component: Simple Fact

Simple facts inherit the common properties of facts.

Properties:

{value}

The value associated with this fact. This may be the special value "nil". The meaning of a fact reported as "nil", the distinction between this and a fact that is not reported, or a fact reported with an empty, or zero, value (where applicable) is implementation dependent.

{base datatype}

The base item datatype for the concept associated with this fact, or the one from which it is derived.

{accuracy}

The number of decimal places to which the value is accurate, or "infinity". The accuracy property is required on, and MUST only be present on, numeric simple facts.

A base item datatype is an XML Schema 1.0 Primitive Built-in Datatype ([XML Schema Datatypes]) from which the type of the XBRL concept definition is derived. In the special case of types derived via the xbrli:dateUnion datatype, this will be either xsd:date or xsd:dateTime depending on the value present on the fact.

A numeric simple fact is a simple fact with a {base datatype} that is derived from the XML Schema type of xsd:decimal, xsd:float or xsd:double.

A boolean simple fact is a simple fact that is derived from the XML Schema type of xsd:boolean.

A string simple fact is a simple fact that is derived from the XML Schema type of xsd:string.

Component: Tuple Fact

Tuple facts inherit the common properties of facts. Note that whilst the {aspects} property is common between tuple facts and simple facts, tuple facts will always have exactly one aspect, the concept core aspect.

Tuple facts serve as a grouping container for other facts. The containment is captured by the tuple parent core aspect on child facts.

Properties:

Component: DTS Reference

Properties:

{type}

Reference type: either "schema" or "linkbase"

{href}

The URL to the defining XML document (schema or linkbase).

3.1 Aspects

An aspect is a piece of additional information that serves to uniquely identify a fact. An aspect may either be one of the core aspects listed below or a taxonomy-defined aspect.

A core aspect is an aspect that is defined by the XBRL v2.1 specification, as distinct from those which are defined in a taxonomy.

Component: Concept Core Aspect

Properties:

{name}

The expanded name corresponding to oim:concept

{value}

An expanded name identifying an XBRL concept.

Constraints:

The concept core aspect is required on all facts.

Component: Entity Core Aspect

Properties:

{name}

The expanded name corresponding to oim:entity

{scheme}

A URI denoting the scheme from which an identifier is drawn.

{identifier}

A string identifying the entity to which the fact relates.

Constraints:

The entity core aspect is required on, and MUST only be present on, simple facts.

Component: Period Core Aspect

The period core aspect represents the period of time, or instant, to which a fact is applicable. Whilst the xBRL-XML representation uses different elements to represent instants and durations, this specification uses a common model for both in the form of an ISO 8601 interval, with instants being represented using a zero-level interval.

Properties:

{name}

The expanded name corresponding to oim:period

{interval}

An ISO 8601 interval or the special value "forever". The interval MAY be zero-length, denoting an instant in time. The interval may or may not include a timezone. Where an interval is specified without a timezone, processors MUST NOT make assumptions about what timezone is intended: instead, the absence of a specified timezone MUST be preserved in the model.

Constraints:

The period core aspect is required on, and MUST only be present on, simple facts.

Component: Unit Core Aspect

Properties:

{name}

The expanded name corresponding to oim:unit

{numerators}

An unordered list of expanded names, identifying individual measures.

{denominators}

An optional, unordered list of expanded names, identifying individual measures.

Constraints:

The unit core aspect is required on, and MUST only be present on, numeric simple facts.

Component: Tuple Parent Aspect

Properties:

{name}

The expanded name corresponding to oim:tupleParent

{parent}

The tuple fact that is the parent of the fact.

Constraints:

This aspect should be absent for facts that do not form part of a tuple fact.

Component: Tuple Order Aspect

Properties:

{name}

The expanded name corresponding to oim:tupleOrder

{order}

An integer value corresponding to the fact's position amongst its siblings within a parent tuple fact. This value is 1-based (the first child has an order value of "1").

Constraints:

This aspect MUST be present if the tuple parent core aspect is present on the fact, and MUST be be absent otherwise.

Component: Language Core Aspect

Properties:

{name}

The expanded name corresponding to oim:language

{language}

The language in which the fact is reported, identified using a BCP 47 language code.

Constraints:

The language core aspect may only be present on string simple facts and is optional on such facts.

Component: Taxonomy-defined Aspect

Properties:

{name}

The expanded name identifying the aspect.

{value}

The value for the aspect.

{base datatype}

The XML Schema 1.0 primitive simple type that defines the value space for the aspect, or the one from which the type for this aspect is derived.

Constraints:

Taxonomy defined aspects MUST only be present on simple facts.

Explicit dimensions will have a type of xsd:QName, but it should be noted that a type of xsd: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 DTS.

3.2 Footnotes

A footnote is either a text footnote or a fact footnote.

Abstract Component: Footnote

A footnote is either a fact footnote or a text footnote. All footnotes share the following common properties.

Properties:

{group}

A URI identifying a grouping of footnotes.

{footnote type}

A URI identifying the type of footnotes in the group.

Component: Fact Footnote

Fact footnotes inherit the properties defined for footnotes.

Properties:

{fact}

A fact that provides the footnote.

Component: Text Footnote

Text footnotes inherit the properties defined for footnotes.

Properties:

{language}

An optional language for the footnote, identified using a BCP 47 tag.

{value}

An XHTML fragment representing the value of the footnote.

[Paul Warren: PWD: It should be noted that the model does not capture the resource role for footnote resources. The working group is actively seeking feedback on this point. It is currently felt that the combination of extended link role ("footnote group") and arcrole ("footnote type") provide adequate scope for customisation and classification of footnotes, and that an additional property is unnecessarily complex and confusing outside of the XML syntax (and thus in the absence of XLink). ]

Appendix A References

DIMENSIONS: XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
GLOBALLEDGER: XBRL International Inc.. "XBRL Global Ledger Framework"
Gianluca Garbellotto.
(See http://xbrl.org/int/gl/2007-04-17/GLFramework-REC-2007-04-17.htm)
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)
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)
XML Schema Datatypes: W3C (World Wide Web Consortium). "XML Schema Part 2: Datatypes Second Edition"
Paul V. Biron, and Ashok Malhotra.
(See http://www.w3.org/TR/xmlschema-2/)

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)

Date	Author	Details
13 January 2016	Paul Warren	First Public Working Draft

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 13 January 2016. 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.

Open Information Model 1.0

Public Working Draft 13 January 2016

Status

Abstract

Comment

Table of Contents

Appendices

Table

Definitions

1 Introduction

1.1 Scope

1.2 Terminology

1.3 Namespaces and namespace prefixes

2 Assumptions

2.1 Non-dimensional segment/scenario content

2.2 Mixing segment and scenario elements

2.3 Complex-typed dimensions

2.4 Use of fractionItemType

2.5 Use of non-standard footnote resource roles

3 XBRL Report Model (non-GL)

3.1 Aspects

3.2 Footnotes

Appendix A References

Appendix B Intellectual property status (non-normative)

Appendix C Document History (non-normative)

Appendix D Errata Corrections incorporated in this document