1 Introduction

Based on the issues documented in the Inline XBRL Use Case document [USE CASES], there is a need to simplify the problem of XBRL rendering. One way of doing this is to allow preparers to produce their reports in an arbitrary format, provide an XHTML representation of this, and then augment the XHTML with Inline XBRL. It is then possible to post-process the XHTML document and extract an XBRL instance document. This standard describes the Inline XBRL syntax.

Inline XBRL addresses five XBRL components: header, contexts, tuples, simple facts, and footnotes. The header is simply the xbrl declaration including namespaces. Inline XBRL also provides meta-data markup to augment the XHTML to manage namespaces, locale formatting, and visibility control. The following sections describe how these are added to an XHTML document.

Inline XBRL is a standard way of embedding additional meta-data or markup into web-readable (i.e. (X)HTML) content in order to facilitate a specific sort of processing. A similar approach has been taken by [INLINE SVG] and [MATHML]

2 Motivation

Publishing financial and business information into a static format is an essential aspect in establishing fixed reference information. Traditionally this was done via "hard copy" printed reports, and recently has shifted to fixed electronic (or "soft copy") versions available through PDFs or on corporate websites. Machine readable formats of the same data in XBRL MUST be tightly coupled to those human readable publications. The original strategy for this within XBRL was to post-process XBRL into the human-readable format, however this has proved challenging to adopt directly. Instead, Inline XBRL starts with an electronically published human readable report and then augments this with the Inline XBRL meta-data markup, thus allowing an XBRL Instance document to be extracted.

The purpose of Inline XBRL, then, is to make it possible to deliver structured, machine-readable data inside a human readable rendering of these data.

3 Overview (non-normative)

The format of an Inline XBRL enhanced XHTML document is straight forward. The XBRL Instance document header, contexts, and static hidden facts are embedded between the head and body XHTML elements. XBRL facts are tagged directly within the XHTML using standard XBRL. Where displayed values are not in the correct XBRL format, meta-data attributes are added to indicate the required transformation. Tuples are supported by wrapping a set of simple facts, possibly with ordering meta-data added, and other standard XHTML formatting. In situations where there is XBRL content which should not be displayed in the human-readable XHTML, a standard approach is provided for concealing the content. Producing a full XBRL Instance document from Inline XBRL consists of appending the tuples and simple facts into the header section with any necessary reformatting, dissolving any XHTML, meta-data markup, and content associated with presentation mark-up and not XBRL.

4 Namespaces

It is required that common browsers of 2007, using an XSLT 1.0 stylesheet, MUST be able to create XHTML when pointed to a document conforming to this specification.

All display formatting elements MUST be in the XHTML namespace http://www.w3.org/1999/xhtml [XHTML]. This allows them to be identified and removed from the extracted XBRL.

XBRL Instance document elements MUST all be in the http://www.xbrl.org/2003/instance namespace [XBRL], with associated XBRL linkbase and XLink elements in the http://www.xbrl.org/2003/linkbase and http://www.w3.org/1999/xlink [XLINK] namespaces respectively.

Inline XBRL does not introduce any elements, however a number of meta-data attributes are defined in this standard. These are all in the http://www.corefiling.com/ns/2007/inlinexbrl namespace.

The following table lists the standard namespace prefixes that are used in this document for each of these namespaces. Inline XBRL does not require any particular prefix to be used for a given namespace, and default namespaces MAY be used as appropriate. By convention and to support XHTML renderers which are not XML Namespace aware it is common to exclusively assign the XHTML Namespace as the default, thereby avoiding the need to use a prefix. [Ian Stokes-Rees: Does XBRL ever require a particular namespace prefix to be used? ] [Ian Stokes-Rees: Should the statement regarding XHTML as the default NS be stronger? E.g. should it state "XHTML Namespace MUST always and only be used via the default namespace declaration"? ]

5 Hiding

Sections of XBRL which are meant to be hidden MUST use the XHTML standard CSS [CSS] style property display: none. There are various strategies for achieving this. Some examples are: the use of an explicit style attribute on the root element of the XML fragment to be hidden; a class attribute on the root element of the XML fragment to be hidden, with a corresponding CSS class definition containing display: none. The addition of class or style attributes to XBRL elements MUST be removed once the XBRL is extracted into a single XBRL Instance document.

6 XBRL Header

The XBRL instance document header, including all namespace declarations and contexts, plus any static XBRL facts or tuples which are not displayed as part of the human-readable XHTML are placed in a section of standard XBRL rooted with the standard xbrli:xbrl element placed within the xhtml:html root element, between the xhtml:html/xhtml:head and xhtml:html/xhtml:body elements. This XML fragment is the only node found by the XPath [XPATH] /xhtml:html/xbrli:xbrl. This XML fragment MUST be hidden as per Section 5 .

7 XBRL Simple Facts

Any portion of the Inline XBRL document (that is, the XHTML document) MAY have XBRL taxonomy elements wrapping a region of text or figures. Any XHTML tags (but not their content) within the XBRL simple fact will be dissolved when transforming the Inline XBRL into an XBRL Instance document. The following table shows some examples of this:

8 XBRL Tuples

[Ian Stokes-Rees: There is an assumption that tuples can always be distinguished from simple facts based exclusively on the presence of a contextRef attribute: all simple facts have one, while tuples never have it. If this assumption is false, then a tag ix:type="simple|tuple" is required to guide processing. ] Tuples are similar to simple facts. Tuples MAY have XHTML content which is not inside an XBRL Fact. This will be removed (tags and text content) in the extracted XBRL Instance document. Tuples MUST contain decendants which are either nested tuples or simple facts. These will form the tuple content.

A degree of XBRL fact reordering within a tuple between the Inline XBRL XHTML document and the extracted XBRL Instance document is possible. The ix:order attribute MAY be added to the immediate children of the parent XBRL tuple element, in order to assert an ordering. The specified ordering MUST correspond to the taxonomy definition ordering for the tuple. The following example shows the Inline XBRL XHTML fragment and the extracted XBRL.

9 Number formatting

10 Text formatting

[Ian Stokes-Rees: This section is not yet complete. It is necessary to define the set of formats, exact format conversions, and how scaling applies to different formats. The current stylesheet does not support ix:format. ] When an XBRL Fact is displayed in a format which is different from that required by the XBRL standard or a particular taxonomy, it is necessary to perform some transformations. Two meta-data attributes are defined to enable these transformations to be done. The first is ix:format which contains a code associated with a particular transformation. Table 1 defines an initial set of transforms. The second is ix:scale, which is a factor used to multiply the Inline XBRL value (after any ix:format transformations, if applicable) to generate the extracted XBRL Fact value. This can be used for power-of-ten scaling, and for sign inversion (positive/negative). [Ian Stokes-Rees: Since factors will always be powers of 10, it would be much nicer for the ix:scale value to be used for power of 10 scaling (i.e 1 = x10, 2 = x100, 3 = x1000, etc), however there also seems to be a need for sign inversion. The most straight forward way of handling this is to add it to ix:scale and simply multiply the Inline XBRL value directly by the ix:scale value. ]

Table 1 

11 Open issues