Copyright ©2010 XBRL International Inc., All Rights Reserved.
Circulation of this supporting document for a Recommendation is unrestricted. 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.
1 Use cases
2 Requirements
3 Relationship to other specifications
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)
The main objective of Inline XBRL 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 Inline XBRL were:
The Rendering Working Group established other uses for Inline XBRL, such as:
These use cases are described more fully in [Inline XBRL Use Cases].
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.
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 Inline XBRL 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 Inline XBRL 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 Inline XBRL 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.
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.
Inline XBRL 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 Inline XBRL.
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 Inline XBRL Document Set 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.
An Inline XBRL Document Set can be edited to update its contents for a new period and maintain consistency of formatting.
If functions in the transformation registry properly convert displayed characters into fact values, then the rendering literally "shows accurately all facts".
The positive and negative signs on values as they appear in the target instance document are preserved in the sense that they must be specified independently of the colouring or other conventions used to display negative values.
While Inline XBRL does not specify a procedure for generating layout purely from XBRL facts or metadata, Inline XBRL exceeds this requirement because rows, columns, cells and nested table layouts can contain any kind of fact value or other content.
This is a further generalisation of 3.07 satisfied in the same way.
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.
Preparers may use HTML's page-break style attributes to achieve similar effects.
Inline XBRL 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.
Inline XBRL complements a rendering process specification by providing a flexible target rendering in which all facts can be embedded adjacent to their renderings.
Inline XBRL can be used with any extension of any taxonomy, which is the point of the requirement.
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 Inline XBRL fulfils this need. In other words, the second half of requirement 3.02 is relevant to a rendering process and not a document.
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).
This document could not have been written without the contributions of many people including the participants in the Rendering Working Group.
Date | Author | Details |
---|---|---|
23 June 2008 | Philip Allen |
Initial draft of background document. |
25 June 2008 | Walter Hamscher |
Substantial edits. |
25 June 2008 | Philip Allen |
Corrected section on validation. Added abstract. |
27 June 2008 | Michael 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 2008 | Jim Richards |
Minor grammatical changes |
27 June 2008 | Philip Allen |
Corrected section on duplication. Added note deprecating HTML generally. |
27 June 2008 | Andy Greener |
Added reference to XML Namespaces. Added reference to XML Schema 1.0. Fixed typos. |
10 July 2008 | Hugh Wallis |
Editorial for publication as support for the inlineXBRL Candidate Recommendation. |
19 August 2008 | Walter Hamscher |
Grammatical fixes suggested by Allyson Ugarte. |
27 August 2008 | Philip Allen |
Added paragraph deprecating non-exact matches in duplicates (s.6.2). |
30 September 2008 | Philip Allen |
Added section on the use of ix:exclude. |
07 October 2008 | Hugh Wallis |
Editorial for publication as support for the inlineXBRL Candidate Recommendation 2. |
20 January 2009 | Hugh Wallis |
Editorial for publication as CR3. |
27 January 2009 | Philip Allen |
Added note on use of xml:base with relative URIs. Added references to XML Base. Added comment about excessive namespace declarations. |
31 March 2009 | Philip Allen |
Added note on prohibition of recursive tuples. Added note on handling of negative numbers. Re-ordered section 6. |
01 April 2009 | Philip Allen |
Extended the discussion of de-duplication. Added discussion of target document content. |
03 April 2009 | Philip Allen |
Removed namespace from ix: attributes, where mentioned. Added note on use of the id attribute. |
06 May 2009 | Philip Allen |
Corrected spelling mistake. |
10 August 2009 | Philip Allen |
Added note on other attributes. |
02 September 2009 | Philip Allen |
Added note on HTML escaping. |
08 September 2009 | Philip 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 2009 | Philip Allen |
Added section on QNames and namespace declarations. Updated reference to main spec. |
23 September 2009 | Philip Allen |
Added paragraph on nesting ix:nonNumeric elements. |
02 October 2009 | Hugh Wallis |
Editorial for publication as CR5 Updated reference links. |
28 October 2009 | Philip Allen |
Added note on provision of page breaks. |
13 November 2009 | Philip Allen |
Added note on de-duplication of tuple children. |
14 November 2009 | Philip Allen |
Added clarification to note on signs. |
16 November 2009 | Philip Allen |
Changed date to 2009-11-16 and status to DCR in expectation of publication as CR6. |
19 November 2009 | Hugh Wallis |
Editorial for publication as CR, approved by the XSB. |
21 December 2009 | Philip Allen |
Added note on the handling of text content (ix:footnote and ix:nonNumeric). |
23 December 2009 | Philip Allen |
Added section on identification of Inline XBRL documents. Added note regarding use of relative hyperlinks between multiple documents. Changed Formal Public Identifier version to 1.0. |
04 January 2010 | Philip Allen |
Added second paragraph in section on signs to explain the constraints on transformations. |
18 January 2010 | Philip Allen |
Updated note on other attributes. Fixed typos. |
20 January 2010 | Philip Allen |
Removed user guidance for move to primer document. |
22 January 2010 | Philip Allen |
Changed date to 2010-01-22 and status to DPR in expectation of publication as PREC. |
27 January 2010 | Hugh Wallis |
Editorial to reflect publication as PR |
01 February 2010 | Philip Allen |
Replaced "iXBRL" with "Inline XBRL". Replaced "IXDS" with "Inline XBRL Document Set". Corrected "can" to "must" in requirement 3.06. Corrected requirements filename reference. |
20 April 2010 | Hugh Wallis |
Editorial for publication of RECOMMENDATION |