Inline XBRL 1.0

Background information and guidance

Supporting document for a Candidate Recommendation 16 November 2009

Copyright ©2009 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/inlineXBRL/CR-2009-11-16/inlineXBRL-background-CR-2009-11-16.html>
Editor:
Philip Allen, CoreFiling Limited <plega@corefiling.com>
Contributors:
Andy Greener, HMRC <andy@gid.co.uk>
Walter Hamscher, Standard Advantage <walter@hamscher.com>
Michael Leditschke, Australian Bureau of Statistics <michael.leditschke@abs.gov.au>
Jim Richards, JDR & Associates <jdrassoc@iinet.net.au>
Hugh Wallis, XBRL International, Inc. <hughwallis@xbrl.org>

Status

Circulation of this supporting document for a Candidate Recommendation is unrestricted. Other documents may supersede this document. Recipients are invited to submit comments to rendering-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document provides background to the Specification for Inline XBRL, and notes of use to authors of Inline XBRL documents.

Table of Contents

1 Background
1.1 Use cases
1.2 Requirements
2 Relationship to other specifications
3 The document set
3.1 Multiple documents
3.2 Use of ID types
4 Processing and validation
4.1 Inline XBRL documents
4.2 Processors
4.2.1 The Conformant Processor
4.2.2 The Validating Conformant Processor
4.3 Validation
4.4 Conformance suite
4.4.1 Use of valid test pairs in the conformance suite
4.4.2 Use of invalid Inline XBRL Document Sets in the conformance suite
5 Transformation rules
6 Style guidance for authors
6.1 Automation
6.2 Content of the target document
6.3 Contexts
6.4 Duplicates
6.5 Escaped HTML
6.6 Equal values
6.7 MIME types
6.8 Namespace declarations
6.9 Nested tags
6.10 Nested tuples
6.11 Page breaks
6.12 QNames in attributes
6.13 Signs
6.14 Other attributes
6.15 Resolving relative URIs
6.16 Totalling
6.17 URIs
7 Discussion of consuming applications
7.1 Hidden elements
7.2 DOM

Appendices

A Relationship to rendering requirements
A.1 Completeness [3.02]
A.2 Adaptability and consistency [3.04]
A.3 Accuracy [3.05]
A.4 Positive and negative signs [3.06]
A.5 Grouping and ordering [3.07]
A.6 Tables [3.08]
A.7 Descriptive headings for sections [3.10]
A.8 Data highlighting [3.11]
A.9 Footnotes [3.13]
A.10 Unbroken data [3.14]
A.11 Embedding of data in text [3.15]
A.12 Handling of text, numbers and monetary values [3.16]
A.13 Referenced taxonomies [3.17]
A.14 Inclusion of formatted content from external source [4.01]
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)


1 Background

1.1 Use cases

The main objective of Inline XBRL ("iXBRL") is to allow XBRL-based data to be displayed in situations where the producer wants to preserve a specific visual presentation of the information, and the consumer wants to be able to validate the input data. The primary use cases which drove the specification of iXBRL were:

  • Preparation of company financials for filing with securities regulator
  • Companies registrar wants to collect extensible business reports
  • Company needs to view data prepared for internal consolidation

The Rendering Working Group established other uses for iXBRL, such as:

  • Display of comparative corporate information on a web-page
  • Reporting of very large financial statements

These use cases are described more fully in [Inline XBRL Use Cases].

1.2 Requirements

The [Inline XBRL Specification] satisfies all requirements in the [PWD Requirements] except those requiring creation and control of rendering metadata at the taxonomy level referred to in requirements 3.1, 3.3 and 3.20, and 3.19 which requires that a solution should not assume a particular file format for a final rendering. It covers all the examples, and also provides features originally deemed out of scope, such as requirement 3.15 related to embedding of data in text.

For a detailed discussion of requirements addressed by the [Inline XBRL Specification], see the appendix below.

2 Relationship to other specifications

The [Inline XBRL Specification] relies upon [XBRL 2.1], [XML], [XML Base] and [XML Names]. By incorporating metadata within the body of an HTML document it carries out a similar task to [MathML] and [SVG], and to that envisaged by both [Microformats] and [HTML5]. Among these standards, however, there is a divergence of approach to the inline encapsulation of metadata.

[MathML] and [SVG] both allow metadata to be incorporated as elements within the HTML document. This is the approach taken by the [Inline XBRL Specification]. However, both [Microformats] and [HTML5] require metadata to be incorporated as attributes to existing HTML elements. The vocabulary for [HTML5] is currently a working draft.

Incorporating XBRL-based metadata within attribute values would add a further layer of complexity to the iXBRL document and be more difficult to comprehend without adding any tangible benefits. The present approach depends upon web browsers continuing not to display XML elements that are not HTML, and this behaviour is very unlikely to change in the foreseeable future.

The present [Inline XBRL Specification] provides a mechanism for encapsulating [XBRL 2.1] metadata within HTML documents, and is supported by a schema document which complies with [Modular XHTML]. The attribute-based alternative, in contrast, depends upon an approach which is still in flux, and likely to remain unstable for some time to come, and therefore should not be used for the [Inline XBRL Specification].

Use cases were put forward only for embedding iXBRL into HTML and XHTML. Although embedding into other document types is appealing, no convincing use cases were forthcoming. Thus, the syntax and processing semantics of iXBRL are largely independent of the container document type, but not entirely so. If and when use cases for other embeddings are put forward, we anticipate that this could be accommodated in any XML document type with a content model open with respect to elements.

3 The document set

3.1 Multiple documents

It was clear that the requirement to encapsulate complete financial statements in iXBRL could lead to the creation of very large HTML files - say, in the region of 5 megabytes for a substantial listed company - which were above current limit for viewing in a web-browser. To get round this limitation, a complete set of iXBRL information can be split across multiple HTML documents. The [Inline XBRL Specification] allows a set of HTML documents, which together may form part of a web-site, to be treated as a single iXBRL document set. 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) for an Inline XBRL Document Set ("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 there is no requirement to validate a mixed-type IXDS.

3.2 Use of ID types

The requirement to allow the IXDS to contain multiple documents means that the relationship between ID attributes and IDREF attributes cannot be handled using conventional IDREF typing per [XML Schema Datatypes].

Use of IDs is scoped across the IXDS rather than the individual iXBRL Document. Thus, an item of type IDREF must have a matching ID somewhere within the IXDS, not necessarily within the individual iXBRL Document ("IXD"). However, XML Schema can only be applied, for validation purposes, to a single document. It follows that documents making up an IXDS can fail schema validation unless IDs are carefully assigned to the right documents (which makes for a de-normalised IXDS, that it would not be desirable to enforce).

One solution would have been to require that schema validation be applied to an IXDS that had been merged to create a single document. However, while the iXBRL 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 make it difficult to validate the document with confidence after the merge.

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

We have therefore concluded that the correct solution is to remove the IDREF and IDREFS types from the XHTML+iXBRL Schema, redefine them as type NCName and replace the implicit schema constraints with appropriate MUSTs within the [Inline XBRL Specification]. These MUSTs are then to be tested by proprietary code within the Validating Conformant Processor, which can do so without concern about the impact of merging on HTML validation.

The id attribute, which is optional, also uses the xs:NCName type, which effectively leaves it to the [Inline XBRL Specification] to enforce uniqueness across the IXDS. By requiring id attributes to be unique across the IXDS it becomes simpler for a processor to identify elements, should that be necessary.

4 Processing and validation

4.1 Inline XBRL documents

The [Inline XBRL Specification] provides for different levels of conforming iXBRL documents. iXBRL documents can be HTML or XHTML. Both must, of course, be valid but only XHTML documents can be validated using the present Modular XHTML Schema.

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

HTML XHTML
Well-formed XML and Valid iXBRL MUST MUST
Validatable against modular XHTML Schema no yes
Validatable by a Validating Conformant Processor against the rules set out in the [Inline XBRL Specification] MAY MUST

It is worth noting that HTML documents are not often well-formed, and that most authoring tools may have more success creating XHTML than well-formed HTML. In general we would strongly recommend the use of XHTML rather than HTML. We retained HTML in the [Inline XBRL Specification] because there was no technical reason short of validation why HTML should not be as acceptable a host for iXBRL as XHTML.

4.2 Processors

The purpose of a processor is to generate XBRL from an IXDS without reference to any taxonomy. Even so, there are different types of processors:

4.2.1 The Conformant Processor

The Conformant Processor must be able to handle multiple input documents (which together comprise the IXDS) and be able to generate multiple XBRL instance documents ("Target Documents").

4.2.2 The Validating Conformant Processor

The requirements for a Validating Conformant Processor are the same as for the Conformant Processor except that, prior to generating the Target Document(s), it must also validate the IXDS. (This requirement to validate the IXDS ONLY applies to XHTML documents.) Consequently, the functionality of a Conformant Processor is a subset of that of the Validating Conformant Processor.

4.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 iXBRL Documents against the 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 Schema are both normative, 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 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].

The Schema for iXBRL uses a modular technique which involves extending the XHTML Schema to accept iXBRL elements within the XHTML document. The Schema also makes use of parts of the schemas for XBRL, but to accomplish this some changes have had to be made to the structure of the XBRL Schemas that are referenced by the iXBRL modular schema. The re-structured schemas logically define identical instance document content models as the normative XBRL Schemas.

4.4 Conformance suite

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

4.4.1 Use of valid test pairs in the conformance suite

The planned conformance suite will consist of pairs of IXDSs and Target Documents. Each pair will be illustrative of a conforming transformation. Both a Conformant Processor and a Validating Conformant Processor will, when processing a given IXDS, generate the associated Target Documents; if it does not, it will not be deemed Conformant.

4.4.2 Use of invalid Inline XBRL Document Sets in the conformance suite

The conformance suite will also include IXDSs that are not valid, which are used only to test Validating Conformant Processors. A Validating Conformant Processor will, when processing an invalid IXDS, generate a failure message.

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

6 Style guidance for authors

XBRL target documents are complex and, as with any sufficiently flexible language, iXBRL provides authors of an IXDS with many ways to create semantically equivalent target documents. Authors should be aware of a few key points to achieve certain desired results and avoid other undesirable ones.

Of course, no amount of style guidance relieves applications that consume iXBRL from the responsibility of correctly interpreting the target document produced by a conformant processor.

6.1 Automation

iXBRL is not a replacement for applications that render XBRL into readable formats, but it complements them by providing an output format that is widely viewable while preserving all of the semantics of the source XBRL. iXBRL helps to close the loop. There are mature products for WYSIWYG editing of HTML and XHTML, but directly inserting tags into these legacy formats that will support the complexity of XBRL data is untested.

6.2 Content of the target document

Every XBRL fact and xlink relationship in the target document must be justified by reference to an appropriate iXBRL element in the input data. This means that the output document may not contain other facts or relationships. (It does not, incidentally, prohibit duplication, if duplicates are present in the input data, except for tuple children.) Nor does it restrict contexts and units, which may be included in the target document whether or not they appeared in the input document.

6.3 Contexts

iXBRL does not specify any way for the text content of HTML 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 HTML 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.

6.4 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, will 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 Conformant Processors are not required to access the DTS, it cannot be assumed that a Conformant Processor will be able to carry out XBRL-level de-duplication. In addition, because it is possible to add user-defined (non-iXBRL) attributes to iXBRL elements, output elements which are XBRL-s-equal may actually contain different attribute-level information.

The iXBRL 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 specification requires that both facts appear in the target document (section 9.2.3 of the [Inline XBRL Specification]. This is not illegal XBRL but it is very much to be deplored. We do not recommend the inclusion of matching facts with different values in the IXDS.

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 iXBRL validation. We consider that the benefits of this restriction, by making it easier to process iXBRL, outweigh any drawbacks.

6.5 Escaped HTML

For certain reporting purposes it is necessary to retain the HTML elements used with the ix:nonNumeric element and to incorporate the HTML elements, in an XML-escaped form, in the target document. The escape attribute is used to indicate that the content of an ix:nonNumeric element is to be handled in this way. The content of the element in the target document will consist of XML-escaped text which excludes any ix:exclude elements (and their content) and ignores the tags of any nested iXBRL elements. XML-escaping may be achieved by escaping individual characters or by using CDATA indicators.

The full definition of XML-escaping can be found in [XML]. The content of the ix:nonNumeric element itself be XML, or escaped XML. If the latter, it may escape each character separately or it may enclose a section in a CDATA block. However the content has been defined, the output in the target document will either be escaped (in the case of XML) or double-escaped (in the case of escaped XML). Thus, the XML <b> Hello World </b> will be output as &lt;b&gt; Hello World &lt;/b&gt; . Double-escaped XML output may be output using a CDATA block, or each escaped character may itself be escaped, thus: the XML > is escaped as &gt; and double-escaped as &amp;gt; . It is up to the processor to determine whether to use CDATA blocks or character escaping, because both options are treated as indistinguishable by the XML specification. Note, however, that (per the XML specification) CDATA blocks cannot be nested.

6.6 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. iXBRL does not support a one-to-many mapping of source text to facts. The correct approach is to tag the text with one of the mappings, and place the other output tag inside an ix:hidden element.

6.7 MIME types

Publishers of iXBRL documents on the web should be aware that even if the document is an XHTML document (and therefore validatable by a Conforming Validating Processor), current browsers will only display the contents of the file correctly as HTML if the content-type has been set to "text/html."

6.8 Namespace declarations

The display of iXBRL documents in different web browsers is, regrettably, sometimes dependent upon the location of the namespace declarations in the document. In particular, placing the HTML namespace declaration (xmlns:html="http://www.w3.org/1999/xhtml") anywhere in the body of the iXBRL document is likely to lead to undefined treatment in many browsers. It is advisable to define the HTML namespace as the default in the root (html) element and nowhere else.

6.9 Nested tags

There is, however, a special case where "dual tagging" of a single piece of displayed text is permissable. 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 the a numeric element. It follows that a series of nested ix:nonNumeric elements will generate a set of potentially recursive outputs in the target document.

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 be converted into 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).

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

6.11 Page breaks

iXBRL supports page breaks in printed output. Markup such as <p style="page-break-before: always" /> will force a page break when the document is printed from most common browsers.

6.12 QNames in attributes

The name attribute is a QName which determines the name of the target XBRL element type. To be valid in the target XBRL document it is essential that the name attribute in the Inline XBRL document falls within the scope of an appropriate namespace declaration. There is a general rule in the specification, 3.3.2, which requires that namespaces are handled in accordance with the namespaces specification, which is interpreted by processors as requiring these declarations to be copied to 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.

6.13 Signs

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

6.14 Other attributes

The XBRL v2.1 Specification allows the addition of attributes, other than those defined in the 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.

One special case is attributes with the http://www.w3.org/2001/XMLSchema-instance namespace name. These are schema-valid in iXBRL and XBRL v2.1 even though they are not explicitly mentioned in the relevant schemas. To avoid confusion, specific reference has been made to them in the iXBRL specification.

6.15 Resolving relative URIs

One practical issue to remember, when creating HTML which is to be carried over (as escaped HTML) into the target document, is that the URIs contained in link references must continue to be resolvable. Section 12.4.1 of the [HTML] specification describes how this has to be done, and we have incorporated it by reference into the iXBRL specification.

URIs in an iXBRL document must either be absolute (and not needing further resolution) or they will be treated as relative URIs and handled according to Section 12.4.1. This states that the HTML base element can be used to set the base URI. Failing that, the base URI will be that provided by the web server used to retrieve the iXBRL document. If that is not possible, the link reference will be resolved with reference to the base URI of the iXBRL document.

However, if the iXBRL document is contained within an email, or is being accessed as a stream by a processor, there will be no base URI to apply to the link reference. The HTML specification states that HTML documents which contain relative URIs are considered "erroneous" if they rely upon the base URI of the current document.

We would therefore strongly recommend that, where relative URIs are used, the HTML base element be used to set the base URI.

6.16 Totalling

A special case of "Equal values" would be a numeric value displayed in the HTML source 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 iXBRL tags at all; the output facts would simply appear as iXBRL tags in the hidden tag.

6.17 URIs

Publishers of iXBRL documents should use xml:base to control the resolution of relative URIs which are to be passed to the target document. In particular, this will apply to the value of the xlink:href attribute.

7 Discussion of consuming applications

In general, it has been assumed that iXBRL will be consumed by standalone processors that will convert the iXBRL into an XBRL instance document which will then be passed on to another application for further analysis or storage. However, some use cases suggest that embedded applications (for instance, JavaScript executed by a browser) might also be used to process the iXBRL.

7.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 HTML markup. iXBRL 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 iXBRL 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 check data in the hidden area to determine whether it appears to have been hidden for good reason.

7.2 DOM

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

Appendix A Relationship to rendering requirements

The phrasing of requirements in [PWD Requirements] assumes that a rendering process produces renderings from an XBRL instance. Naturally, in making that assumption, some legitimate business requirements - such as the need for a trail or link from a target document fragment to its source facts - seemed too difficult or out of scope.

iXBRL does not define such a generation method, but insofar as it specifies a means of embedding XBRL in HTML, it satisfies some of the same business needs as rendering, it satisfies additional needs of regulators and preparers, and it thereby complements a rendering process [Inline XBRL Specification] rather than competing with it. This section details the requirements met by iXBRL.

A.1 Completeness [3.02]

The first half of the requirement - that "a standardised rendering method MUST be able to reproduce completely all facts in an instance, including all data types and footnotes, without loss of data" - is satisfied because nothing can be extracted from the IXDS except target instance documents. The second half of this requirement - that "no other information is included in an instance which is not represented in the rendering" - is not a completeness requirement and is not met.

A.2 Adaptability and consistency [3.04]

An IXDS can be edited to update its contents for a new period and maintain consistency of formatting.

A.3 Accuracy [3.05]

If functions in the transformation registry properly convert displayed characters into fact values, then the rendering literally "shows accurately all facts".

A.4 Positive and negative signs [3.06]

The positive and negative signs on values as they appear in the target instance document are preserved in the sense that they can be specified independently of the colouring or other conventions used to display negative values.

A.5 Grouping and ordering [3.07]

While iXBRL does not specify a procedure for generating layout purely from XBRL facts or metadata, iXBRL exceeds this requirement because rows, columns, cells and nested table layouts can contain any kind of fact value or other content.

A.6 Tables [3.08]

This generalisation of 3.07 is satisfied in the same way as 3.07.

A.7 Descriptive headings for sections [3.10]

This is a further generalisation of 3.07 satisfied in the same way.

A.8 Data highlighting [3.11]

This is partly satisfied in the sense that cascading styles such as "emphasis" or "strong" and relative point sizes can be specified in HTML and applied to any text that appears in facts.

A.9 Footnotes [3.13]

Preparers using iXBRL can specify all aspects of footnote layout.

A.10 Unbroken data [3.14]

Preparers may use HTML's page-break style attributes to achieve similar effects.

A.11 Embedding of data in text [3.15]

iXBRL satisfies this requirement; it is an example of functionality deemed out of scope for a rendering process, even though the business need was already widely recognized for regulatory environments where quantitative disclosures commonly appear in narrative text.

A.12 Handling of text, numbers and monetary values [3.16]

iXBRL complements a rendering process specification by providing a flexible target rendering in which all facts can be embedded adjacent to their renderings.

A.13 Referenced taxonomies [3.17]

iXBRL can be used with any extension of any taxonomy, which is the point of the requirement.

A.14 Inclusion of formatted content from external source [4.01]

The rejection of this requirement was a consequence of the second half of requirement 3.02, which required the rendering to contain no information that was not in the instance nor its DTS, even though other business users of XBRL see value in this function. XInclude, for example, allows HTML documents to include content from other sources, implying that iXBRL fulfils this need. In other words, the second half of requirement 3.02 is relevant to a rendering process and not a document.

Appendix B References

C14N
W3C (World Wide Web Consortium). "Canonical XML"
John Boyer.
(See http://www.w3.org/TR/xml-c14n)
HTML
W3C (World Wide Web Consortium). "HTML 4.01 Specification"
Dave Raggett, Arnaud Le Hors, and Ian Jacobs.
(See http://www.w3.org/TR/html401/)
HTML5
W3C (World Wide Web Consortium). "HTML 5: A vocabulary and associated APIs for HTML and XHTML"
Ian Hickson, and David Hyatt.
(See http://www.w3.org/TR/html5/)
Inline XBRL Specification
XBRL International Inc.. "Inline XBRL Part 1: Specification 1.0"
Philip Allen, and Ian Stokes-Rees.
(See http://www.xbrl.org/Specification/inlineXBRL-part1/CR-2009-11-16/inlineXBRL-part1-CR-2009-11-16.html)
Inline XBRL Use Cases
XBRL International Inc.. "Use cases for Inline XBRL 1.0"
John Turner.
(See http://www.xbrl.org/Specification/inlineXBRL/CR-2009-09-28/inlineXBRL-useCases-CR-2009-09-28.html)
MathML
W3C (World Wide Web Consortium). "Mathematical Markup Language (MathML) Version 2.0 (Second Edition)"
David Carlisle, Patrick Ion, Robert Miner, and Nico Poppelier.
(See http://www.w3.org/TR/MathML2/)
Microformats
"Microformats Principles"
Tantek Çelik.
(See http://microformats.org/wiki/principles)
Modular XHTML
W3C (World Wide Web Consortium). "XHTML Modularization 1.1"
Murray Altheim, Frank Boumphrey, Sam Dooley, Shane McCarron, Sebastian Schnitzenbaumer, and Ted Wugofski.
(See http://www.w3.org/TR/xhtml-modularization/)
PWD Requirements
XBRL International Inc.. "XBRL Rendering Requirements, Public Working Draft dated 2007‑07‑24"
Peter Calvert.
(See http://www.xbrl.org/technical/requirements/REN-REQ-PWD-2007-07-24.rtf)
SVG
W3C (World Wide Web Consortium). "Scalable Vector Graphics (SVG) 1.1 Specification"
Jon Ferraiolo, Jun Fujisawa, and Dean Jackson.
(See http://www.w3.org/TR/SVG/)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)
XML
W3C (World Wide Web Consortium). "Extensible Markup Language (XML) 1.0 (Fifth Edition)"
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau.
(See http://www.w3.org/TR/REC-xml/)
XML Base
W3C (World Wide Web Consortium). "XML Base"
Johnathan Marsh.
(See http://www.w3.org/TR/xmlbase/)
XML Names
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)
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 C 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 D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Rendering Working Group.

Appendix E Document history (non-normative)

DateAuthorDetails
23 June 2008Philip Allen

Initial draft of background document.

25 June 2008Walter Hamscher

Substantial edits.

25 June 2008Philip Allen

Corrected section on validation.

Added abstract.

27 June 2008Michael Leditschke

Added definition for IXDS

Reworded discussion of scope of XML Schema.

Corrected use of IXDS in s.4.

Re-worded description of changes to XBRL Schemas.

Fixed minor typos.

27 June 2008Jim Richards

Minor grammatical changes

27 June 2008Philip Allen

Corrected section on duplication.

Added note deprecating HTML generally.

27 June 2008Andy Greener

Added reference to XML Namespaces.

Added reference to XML Schema 1.0.

Fixed typos.

10 July 2008Hugh Wallis

Editorial for publication as support for the inlineXBRL Candidate Recommendation.

19 August 2008Walter Hamscher

Grammatical fixes suggested by Allyson Ugarte.

27 August 2008Philip Allen

Added paragraph deprecating non-exact matches in duplicates (s.6.2).

30 September 2008Philip Allen

Added section on the use of ix:exclude.

07 October 2008Hugh Wallis

Editorial for publication as support for the inlineXBRL Candidate Recommendation 2.

20 January 2009Hugh Wallis

Editorial for publication as CR3.

27 January 2009Philip Allen

Added note on use of xml:base with relative URIs.

Added references to XML Base.

Added comment about excessive namespace declarations.

31 March 2009Philip Allen

Added note on prohibition of recursive tuples.

Added note on handling of negative numbers.

Re-ordered section 6.

01 April 2009Philip Allen

Extended the discussion of de-duplication.

Added discussion of target document content.

03 April 2009Philip Allen

Removed namespace from ix: attributes, where mentioned.

Added note on use of the id attribute.

06 May 2009Philip Allen

Corrected spelling mistake.

10 August 2009Philip Allen

Added note on other attributes.

02 September 2009Philip Allen

Added note on HTML escaping.

08 September 2009Philip Allen

Added a second paragraph on HTML escaping.

Added a section on resolution of relative URIs within HTML which is to be escaped.

22 September 2009Philip Allen

Added section on QNames and namespace declarations.

Updated reference to main spec.

23 September 2009Philip Allen

Added paragraph on nesting ix:nonNumeric elements.

02 October 2009Hugh Wallis

Editorial for publication as CR5

Updated reference links.

28 October 2009Philip Allen

Added note on provision of page breaks.

13 November 2009Philip Allen

Added note on de-duplication of tuple children.

14 November 2009Philip Allen

Added clarification to note on signs.

16 November 2009Philip Allen

Changed date to 2009-11-16 and status to DCR in expectation of publication as CR6.

19 November 2009Hugh Wallis

Editorial for publication as CR, approved by the XSB.