1 Overview

This document serves to document the motivation behind certain design decisions made in the Open Information Model, including the constraints that limit certain XBRL v2.1 features documented in the xBRL-XML specification.

2 Use of the XML Schema datatype system

A key goal of the Open Information Model was to create a model that was syntax-independent, implying that there should be no dependency on XML or XML-related specifications.

The model does require a type system, and although XML Schema as a whole is very much XML-specific, the system that it defines for specifying simple datatypes is largely independent of XML. It specifies a lexical representation for each type that is a string that could be included in just about any other format.

The XML Schema datatype system (XSD) is very complete, and other, non-XML technologies have seen the value in reusing it. For example, the JSON-LD specification includes many examples that make use of XSD.

3 Simplification of taxonomy references

XBRL v2.1 permits an instance to reference its taxonomy through a combination of schemaRef, linkbaseRef, roleRef and arcroleRef elements. The XBRL instance schema requires elements to appear in the above order; all schemaRef elements must appear first, followed by any linkbaseRef elements, then any roleRef elements, and finally arcroleRef elements. In certain situations, the order of DTS discovery is significant, and as such, the order of DTS references needs to be preserved in the model.

In the long term, we expect taxonomies to move to non-XML-based representations, and it is likely that the URLs used for specifying DTS entry points will become pure identifiers. As such, the Working Group was keen to simplify the definition of the taxonomy entry point to a single list.

The ordering requirements of entry points consisting of a mix of different document types makes this inherently difficult and cumbersome, as it is effectively multiple lists, and processors need to know the type of each reference in order to preserve order correctly.

The Working Group could not find any examples of linkbases being referenced directly from an instance document. Similarly roleRef, and arcroleRef usage is very limited, as they are only included where necessary to meet the syntactic requirements of XBRL v2.1 footnotes for custom roles and arcroles.

As such, it was decided to apply the simplifying constraint that an instance's DTS must be specified only by a list of schemas.

3.1 Serialisation of roleRef and arcroleRef elements

When creating an xBRL-XML representation of an OIM report, it is necessary to include roleRef and arcroleRef elements for any custom roles or arcroles used by footnotes in the report. Provided that the location of the relevant roleType or arcroleType element is known, an appropriate roleRef or arcroleRef can be created automatically.

The approach taken is to require that any custom roles or arcroles used in an OIM XBRL report are defined in either the DTS of the report (or in the case of xBRL-XML, the DTS discoverable considering only schemaRef elements), or in the XBRL Link Role Registry.

The error code xbrlxe:unsupportedExternalRoleRef is prescribed if an xBRL-XML report does not meet this constraint, and xbrlxe:nonStandardRoleDefinitionNotInDTS if an OIM XBRL report does not meet the constraint. The latter code must be raised by Validating Conformant Processors when loading such a report from xBRL-CSV, xBRL-JSON or any other OIM-based format.

This constraint is expected to have a very low impact. The only known use of custom roles or arcroles on footnotes is the fact-explanatoryFact footnote arcrole, which is defined in the Link Role Registry.

It is expected that any custom roles or arcroles that are not in the LRR will be in the DTS of the report, and if not, rearranging the DTS so that they are should be straightforward.

4 Inclusion of fact identifiers in the model

Although fact identifiers do not contribute to the semantic meaning of a fact, they are potentially useful in providing the ability to trace an individual fact through different representations, for example, by allowing the easy tracing of a fact in an xBRL-JSON document back to its source in an Inline XBRL document.

The OIM provides separate definitions of "equality" and "equivalence" for both facts and reports, with facts that differ only in their identifier being considered equivalent but not equal.

Fact identifiers are mandatory in the model, and the xBRL-XML specification prescribes a standard approach for generating predictable IDs where they are not present in an xRBL-XML report.