2.1 The Inline XBRL Document

The Inline XBRL Document is typically a single XHTML document which, when displayed in a browser, provides a full visual rendering of given XBRL data. An Inline XBRL processor (a "Processor"), given that Inline XBRL Document, will generate an XBRL instance document.

In the Inline XBRL Document, data values are nested within Inline XBRL Elements which are themselves nested within HTML or XHTML elements ("Markup Elements"). This technique relies upon the ability of browsers to ignore XML elements that it does not recognise. The browser, in effect, ignores the Inline XBRL Elements and displays the data values as though they were textual content of the Markup Elements. A Processor will ignore the Markup Elements and combine the Inline XBRL Elements and the data values to generate an XBRL instance document (the "Target Document").

2.2 Multiple documents

Current browsers impose an effective maximum size limit on the files that they can handle. The financial statements for a large company, which might be in the order of five megabytes in size, are too large for most browsers to handle today.

To get round this limitation, a complete set of Inline XBRL information can be split across multiple documents. The [Inline XBRL Specification] allows a set of documents, which together may form part of a web-site, to be treated as a single Inline XBRL Document Set ("IXDS"). There are few restrictions relating to the division of metadata between the different documents in the document set, so it is open to the author to repeat metadata across documents or to abstract common metadata (such as context information) into a header document.

The [Inline XBRL Specification] allows (although it does NOT recommend) the IXDS to consist of both HTML and XHTML documents. The [Inline XBRL Specification] requires that a Validating Conformant Processor validate any XHTML documents against the Schema, but it will not validate or process a mixed-type IXDS.

2.3 Target documents

Inline XBRL allows more than one Target Document to be created from the Inline XBRL Document, so as to make it possible to take two (or more) separate XBRL reports and display the data in a single web page. This allows the author to build an HTML page which combines comparative data from different companies which, when processed, would become a set of financial reports, one for each company.

But it is important not to confuse the mechanism for multiple input documents (i.e., the IXDS) with that for multiple output documents (i.e. Target Documents). It was never the intention that the multiple documents in the IXDS would map into multiple Target Documents, although it is possible to construct an IXDS in this way. Any two random Inline XBRL Documents - which, when processed would create individual Target Documents - will often not be suitable to be treated as constituent parts of the same IXDS, because of the need to ensure that IDs and references are unique across the IXDS, and that the target attributes are set appropriately.

Each Inline XBRL Element is mapped to a given Target Document. The Target Document is identified logically (but not physically) by means of the "target" attribute (if any) on that Inline XBRL Element. If there is no target attribute then the Inline XBRL Element will map to the "default" Target Document.

There is no distinction, other than the convenience of the specification, between specified Target Documents and the default Target Document. It follows that, if there are no target attributes, there will be only one Target Document and that will be the default Target Document. On the other hand, if target attributes are set on all the appropriate Inline XBRL Elements, there will be no default Target Document, and if the value of all those target attributes is the same then there will be only one Target Document.

It follows that, if the target attribute is never specified in the IXDS, all output will be mapped to the same, single, Target Document. If target attributes are provided in some cases but not in others there will always be at least two Target Documents produced. Note that it is never possible to map the same element to more than one Target Document (although it may be possible to map the same data to more than one Target Document by the use of XML nesting).

2.4 Use of ID types

Because Inline XBRL can use multiple documents, use of IDs and IDREFs is scoped across the IXDS rather than the individual Inline XBRL Document. Thus, an item of type IDREF must have a matching ID somewhere within the IXDS, not necessarily within the same Inline XBRL Document. However, the conventional method of IDREF typing (as defined in [XML Schema Datatypes]) can only be applied, for validation purposes, to a single document.

We considered requiring that schema validation be applied to an IXDS that had been merged to create a single document. However, while the Inline XBRL Elements in the IXDS can be merged without danger to the semantics, the Markup Elements cannot. There are issues relating to merging common elements - like HTML, HEAD and BODY - which would make it difficult to validate the document with confidence after the merge.

The problem is that schema validation using the XHTML Modular Schema covers both the Inline XBRL elements and the Markup Elements. Given that the merge can have unpredictable results on the validity of the XHTML, it is sensible to restrict schema-level validation to each individual Inline XBRL Document rather than the IXDS.

We have accordingly avoided IDREF and IDREFS types in the [Inline XBRL Schema], making use of xs:NCName types instead, replacing the implicit schema constraints with appropriate MUSTs within the [Inline XBRL Specification]. These MUSTs are then tested by proprietary code within the Validating Conformant Processor, which can do so without concern about the impact of merging on XHTML validation.

We have taken the same approach with the optional id attribute, which uses the xs:NCName type, and is required by the [Inline XBRL Specification] to be unique across the IXDS. By requiring id attributes to be unique across the IXDS it becomes simpler for the Processor to identify elements, should that be necessary.

3.1 Inline XBRL documents

The [Inline XBRL Specification] provides for different levels of conforming Inline XBRL documents. Inline XBRL documents will generally be HTML or XHTML. They can also, in theory, be any other well-formed XML dialect. All must, of course, be compliant with the specification but only XHTML documents can be validated using the normative [Inline XBRL Schema].

The following table summarises the validation framework for Inline XBRL documents. It is described in fuller detail in the following paragraphs.

The specification, however, does not outlaw non-XHTML dialects because we wanted to encourage as-yet unforeseen uses of Inline XBRL to develop in the future with the full benefit of the specification. There is, in fact, no technical reason short of validation why non-XHTML dialects should not be as acceptable a host for Inline XBRL as XHTML.

3.2 Processors

The purpose of the Processor is to generate XBRL from an IXDS without reference to any taxonomy. Even so, there are different types of Processors:

3.3 Validation

Validation is the process which must be carried out in full by a Validating Conformant Processor on any XHTML document. Validation involves:

1. testing that the IXDS meets the rules set out in the [Inline XBRL Specification]; and
2. validating each of the Inline XBRL Documents against the [Inline XBRL Schema].

For the purposes of the conformance suite, a set of Schematron rules have been created, which test many of the rules set out in the [Inline XBRL Specification]. Together, the Schematron rules and the Schema provide nearly-complete coverage of all the requirements of the [Inline XBRL Specification].

Note that while the rules in the [Inline XBRL Specification] and the [Inline XBRL Schema] are both normative (the latter only for XHTML-based documents), the Schematron rules are non-normative. This is because the Schematron rules are encapsulations of the (normative) MUSTs in the [Inline XBRL Specification], while the [Inline XBRL Schema] covers concepts which are not in all cases made explicit in the [Inline XBRL Specification].

The implication of this is that application of the Schematron rules will NOT necessarily meet the requirement for a Validating Conformant Processor to test that the IXDS meets the rules set out in the [Inline XBRL Specification].

3.4 Conformance suite

The conformance suite is used to test a Processor and has no role in determining the validity of a given Inline XBRL Document.

3.5 Identification of Inline XBRL documents

4.1 Transformation Rules

The [Inline XBRL Specification] provides examples of Transformation Rules, but the normative list will be maintained separately. The transformations will require different implementations for different execution environments.

Transformation Rules may be thought of as parsing rules; they convert textual displays into XML Schema data types having canonical lexical representations along with XBRL specific attributes. Transformation Rules producing types derived from xs:decimal, in particular, must interpret the decimals and precision attributes and produce not only a canonical lexical representation but also corresponding decimals and precision attributes.

There is a long tail of potentially useful transformations to parse currency symbols, dates (in a variety of formats), Boolean values, texts written right-to-left, Chinese, and other display formats. The registry is a practical means for covering a large set of critical numeric and date types for browser execution, XSL and other key environments, while allowing for growth in the set of transformations and implementations.

4.2 Transformation Rules Registries

Transformation Rules are stored in a Transformation Rules Registry which may consist of multiple versions, over time. Within a registry a function is identified by its local name, with the presumption that the function assigned to that local name will never change. Functions will persist from one version of the registry to the next, and only be dropped from subsequent versions in the case of deprecation. This allows the creation of a set of Transformation Rules and their amendment over time while maintaining clarity as to content and purpose.

A given registry is identified by its namespace, which will incorporate the date that that version of the registry was accorded REC status. This neatly resolves the issue of errata corrections - because errata don't have a REC date they can't have a separate namespace and so must be identified with any reference to the underlying registry version.

For developers, the namespace mechanism provides both clarity as to the identification of the set of functions being supported, and a simple way to upgrade provision from one version of a registry to another.

4.3 The Specified Registry

The Specified Registry is the initial version of the registry defined by XBRL International and which is required to be supported by any processor which supports Inline XBRL. It should be noted that subsequent versions of that registry are not required to be supported, although we would expect that implementations of Inline XBRL will probably seek to do so.

It was intended by the authors of the specification that the Specified Registry would meet the needs of regulators and other users of Inline XBRL. The registry framework, as described above, nevertheless provides a clean mechanism for the creation and maintenance of other registries by third parties.

It should be noted that the namespace name given to the Specified Registry was changed when the specification was accorded REC status (so as to incorporate the REC date) and is therefore not the same namespace name as was published in the Proposed REC and previous versions of the specification.

5.1 Contexts

Inline XBRL does not specify any way for the text content of Markup Elements displayed in a browser to be transformed into the content of contexts in the target documents. Dates appearing in column headings, for example, normally appear in the IXDS as Markup Elements without any Inline XBRL Element ancestors. Management of the contexts referenced by xbrli:contextRef attributes in the IXDS is done as in any other XBRL creation process.

5.2 Duplicates

Financial statements normally have at least a handful of facts that appear in more than one location in an IXDS. Net Income, for example, may appear both on an Income Statement and a Statement of Cash Flows. If both occurrences in the IXDS are tagged with the same element and context, and have the same actual or default {target} property, the output may contain both occurrences.

In some cases it will be desired that such occurrences ("duplicates") are removed from the output. However, the rules for de-duplication will vary from occasion to occasion. Duplicates as defined by the XBRL v2.1 Specification can only be determined by reference to the DTS. Because Processors are not required to access the DTS, it cannot be assumed that a Processor will be able to carry out XBRL-level de-duplication. In addition, because it is possible to add user-defined (non-Inline XBRL) attributes to Inline XBRL Elements, output elements which are XBRL-s-equal may actually contain different attribute-level information.

The [Inline XBRL Specification] therefore allows de-duplication to be carried out at the discretion of the Processor.

In some cases, either because of different rounding conventions or by mistake, a pair of facts may match as to element name, context and {target} property, but may have different values. The [Inline XBRL Specification]requires that both facts appear in the Target Document. This is not illegal XBRL but it is very much to be deplored.

In the case of tuple children, however, the creation of duplicates in the target document will often be schema-invalid. For this reason, duplicate tuple children are removed prior to mapping. To keep the Processor as light-weight as possible, duplicates for these purposes are defined as those with the same tuple order value. To validate that these two elements do indeed have the same value, a string-comparison mechanism is used. This is more restrictive than the XBRL v2.1 Specification, which allows (say) for two elements with the same value to use different schemaRef attributes. Such elements would fail Inline XBRL validation. We consider that the benefits of this restriction, by making it easier to process Inline XBRL, outweigh any drawbacks.

5.3 Equal values

An author might wish for a fragment of text in an IXDS to correspond to more than one fact in a Target Document. For example, a formatted date such as "25 June 2008" may need to appear in the target document both as a tuple with day, month and year, and separately as an item of type dateTime. Inline XBRL does not support a one-to-many mapping of source text to facts.

5.4 Totalling

A special case of "Equal values" would be a numeric value displayed in the Inline XBRL Document that is meant to map to more than one output fact, the sum of which is the displayed total. (Note that in some regulatory environments, this would clearly not be acceptable.) The displayed figure would have no Inline XBRL tags at all; the output facts would simply appear as Inline XBRL Elements inside the ix:hidden element.

5.5 Nested tags

There is, however, a special case where "dual tagging" of a single piece of displayed text is permissible. Individual pieces of data which fall within an ix:nonNumeric tag may also themselves be tagged. So a textual note can be tagged as ix:nonNumeric and parts of the text (say, a fraction) can also be tagged (in this case, as ix:fraction). That fraction will appear twice in the target document, once as part of the textual note and once as a numeric fact.

A single date within ix:nonNumeric tags could, for instance, be nested inside a further set of ix:nonNumeric tags. The date would appear twice in the target document, once for each ix:nonNumeric element. If the date was in the form, say, "July 14, 1789" then both ix:nonNumeric elements would include the attribute format="ixt:datelongus", and both dates in the Target Document would appear in the canonical form "1789-07-14".

By using the ix:exclude element it is possible to remove part of the content of the ix:nonNumeric element from the output in the Target Document. But any ix: tags which are nested within that ix:exclude element will continue to be processed in their own right (although no longer as part of the host ix:nonNumeric element).

5.6 Nested tuples

Tuples can be nested, either physically or by reference (the latter by using tupleRef and tupleID). There is no limit to the recursion, except that it is not permitted for tuple content to include, in its own tuple content, the parent tuple.

5.7 Signs

Inline XBRL requires that numerics (ix:denominator, ix:numerator and ix:nonFraction) must use the sign attribute to indicate negative values. Any negative indicator (dash, brackets, or colour-coding) must be positioned in the Inline XBRL Document outside the relevant Inline XBRL Element. The content of the relevant Inline XBRL Element will therefore always be a non-negative number, unless the format attribute is present and a transformation is thus indicated.

Data values which are to be transformed must either represent non-numerics (e.g. dates) or they must also represent (allowing for commas and other formatting) non-negative numerics. No transformation may be used to change the sign of the content. This enforces the general requirement that all numeric values in Inline XBRL are always positive, and values which are required to be negative in the Target Document may only be represented by use of the sign attribute.

5.8 Other attributes

[XBRL 2.1] allows the addition of attributes, other than those defined in the [Inline XBRL Specification], to an XBRL instance document. For instance, it may be desired to give xml:id attributes to elements in the XBRL instance document. Inline XBRL allows the matching addition of "other attributes", in a number of places, to provide for this.

Note that for some elements (ix:footnote, ix:denominator and ix:numerator) the definition of "other attributes" is explicitly more permissive than is the attribute model for that element. This is because definitions which explicitly matched the attribute model would not, in fact, encompass attributes such as those with the http://www.w3.org/2001/XMLSchema-instance namespace name which are not referenced in the schema but which are legal in both Inline XBRL and XBRL v2.1. In the case of ix:denominator and ix:numerator, attributes with the http://www.w3.org/2001/XMLSchema-instance namespace name are actually the only legal members of "other attributes".

6.1 Markup elements in text data

The Inline XBRL equivalents to XBRL text-based facts are ix:footnote and ix:nonNumeric. There are some important differences in the treatment of the content of these elements. Neither has any restriction on element content; in practice this means the content may be ix: elements or Markup Elements. Both can therefore accommodate the nesting of ix: elements and both use the ix:exclude element to remove content from the mapped data.

However, they are very different in their treatment of Markup Elements. In Inline XBRL, most Markup Elements are discarded upon processing, but this is not the case for ix:footnote and ix:nonNumeric. The ix:footnote element includes full Markup Elements in its mappable value, in conformance with the content model for link:footnote in [XBRL 2.1]. However, [XBRL 2.1] does not allow Markup Elements in non-numeric facts. Inline XBRL provides that Markup Elements are only mapped to the Target Document if the escape attribute has been set to true, in which case the Markup Elements are XML-escaped in the Target Document. If the escape attribute is false, the HTML or XHTML tags are discarded prior to mapping.

6.2 XML-escaping

XML-escaped Markup Elements, where they are found in non-numeric XBRL facts, is used most commonly in US SEC reporting, to provide some local formatting for large blocks of text.

XML-escaping may be achieved by escaping individual characters or by enclosing the text in a CDATA block. It is up to the Processor to determine whether to use CDATA blocks or character escaping, because both options are treated as equivalent in [XML].

The full definition of XML-escaping can be found in [XML]. In Inline XBRL, XML-escaping applies both to Markup Elements and Markup Elements that have already been escaped in the original ix:nonNumeric element. In the latter case, the mapped output will be "double-escaped". Note, however, that the XML specification forbids the nesting of CDATA blocks.

By way of example, the XML <b> Hello World </b> will be output as &lt;b&gt; Hello World &lt;/b&gt; . The XML > , which is escaped as &gt; , would be double-escaped as &amp;gt; .

7.1 MIME types

The MIME type selected for the Inline XBRL Document will often have an impact on whether browsers display the document correctly. The MIME type can be set within the Inline XBRL Document with code such as: <meta content='text/html; charset=utf-8' http-equiv='Content-Type' /> .

It should also be noted that browsers may also depend upon the filename suffix in order to determine display behaviour.

7.2 Namespace declarations

The display of Inline XBRL documents in different browsers is, regrettably, sometimes dependent upon the location of the namespace declarations in the document. In particular, placing the XHTML namespace declaration (xmlns:html="http://www.w3.org/1999/xhtml") anywhere in the body of the Inline XBRL document is likely to lead to undefined treatment in many browsers.

7.3 Page breaks

Inline XBRL supports page breaks in printed output.

7.4 QNames in attributes

In Inline XBRL, the name of the XBRL element type in the Target Document is determined by the value of the relevant name attribute in the Inline XBRL Document. The name attribute is a QName, that is, it is in the form namespace prefix:local name.

So that the namespace prefix can be expanded to the underlying namespace name, it is essential to make sure that all name attributes fall within the scope of the appropriate namespace declaration.

There is a general rule (Section 3.3.2 of the [Inline XBRL Specification]) which requires that namespaces are handled in accordance with the namespaces specification, which is interpreted by Processors as requiring these declarations to be made available within the Target Document.

Note that it should not be necessary to provide a namespace declaration for every name attribute. As long as there is an appropriate namespace declaration in scope for the attribute, the QName will be treated correctly in the Target Document.

Canonicalisation [C14N] of the Inline XBRL document, which will remove similar namespace declarations with an overlapping scope, will not have any impact on the validity of the Target Document.

7.5 URIs in Markup elements

Markup which is mapped to the target document (as is the case with Markup Elements included in ix:footnote elements and some ix:nonNumeric elements) may contain URIs.

In HTML and XHTML, URIs may be absolute or relative. In the absence of any alternative, relative URIs will be converted to absolute URIs by Processors using contextual information (such as current document location). This is unattractive for Inline XBRL, where the Inline XBRL document may be part of an electronic filing with no pre-determined location, and can lead to unpredictable results.

This topic is covered more fully in section 12.4.1 of the [HTML] specification.

7.6 URIs in Inline XBRL Elements

Inline XBRL Element URIs, like URIs in Markup Elements, need to be capable of resolution to absolute URIs as part of the mapping process. A common example of this is the xlink:href attribute.

The resolution of relative URIs in Inline XBRL Elements is controlled by the xml:base attribute.

8.1 Hidden elements

Some elements which are required in the XBRL are not expected to be displayed. For instance, a value may be repeated several times in an XBRL instance document, each time as a different concept. Where the convention is only to display this value once, the other occurrences are not displayed in the Markup. Inline XBRL uses the convention that such values will be placed in the ix:hidden element.

However, use of the hidden area opens the possibility that data which will in due course be processed and validated may be deliberately hidden from view. We expect that applications consuming Inline XBRL for further processing will search for tagged data which has not been displayed, to check that it is properly placed in the hidden area. Likewise, the consuming application would provide users with a way to inspect data in the hidden area.

8.2 DOM

There is a general caution with respect to Inline XBRL for in-browser processing. Inline XBRL uses several XML namespaces to provide for more reliable data processing. Within the browser, however, different browsers may expose Inline XBRL Elements to the [HTML DOM] in different ways. Web designers looking to access Inline XBRL metadata should be careful to take this into account.