Copyright ©2008 XBRL International Inc., All Rights Reserved.
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.
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 Contexts
6.2 Duplicates
6.3 Equal values
6.4 Totalling
6.5 MIME types
6.6 Automation
7 Discussion of consuming applications
7.1 Hidden elements
7.2 DOM
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 ("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:
The Rendering Working Group established other uses for iXBRL, such as:
These use cases are described more fully in [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] and [XML Namespaces]. 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]. Between 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]. [Microformats] and [HTML5]. However, both 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.
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 validates any XHTML documents against the Schema, but there is no requirement to validate a mixed-type IXDS.
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 was applied to an IXDS which 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 [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.
The purpose of a processor is to generate XBRL from an IXDS without reference to any taxonomy. Even so, there are different types of 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").
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.
Validation is the process which must be carried out in full by a Validating Conformant Processor on any XHTML document. Validation involves:
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 which are referenced by the iXBRL modular schema. The re-structured schemas logically define identical instance document content models as the normative XBRL schemas.
The conformance suite is used to test a processor and has no role in determining the validity of a given iXBRL Document.
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.
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.
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, tests 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 that growing set of transformations and implementations.
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 desired results and avoid 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.
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.
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 will contain only one instance of that fact. Section 3.2 of the [Inline XBRL Specification] enforces this behaviour by requiring Conformant Processors to output only the minimum necessary information.
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.
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.
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."
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.
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.
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 appeared to have been hidden for good reason.
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.
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, satisfies additional needs of regulators and preparers, and thereby complements a rendering process [Inline XBRL Specification] rather than competing with it. This section details the requirements met by iXBRL.
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.
An IXDS 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 can be specified independently of the colouring or other conventions used to display negative values.
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.
This is a further generalization 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.
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.
iXBRL complements a rendering process specification by providing a flexible target rendering in which all facts can be embedded adjacent to their renderings.
iXBRL 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 2nd half of requirement 3.02, which required the rendering to contain no information 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.
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. |