XBRL 2.1 Conformance Suite 1.0
Candidate Recommendation of 2005-04-25
This document:
XBRL-CONF-CR1-2005-04-25.htm
is a non-normative version of this specification. The NORMATIVE version is in the file
http://www.xbrl.org/2005/XBRL-CONF-CR1-2005-04-25.rtf
Source files:
http://www.xbrl.org/2005/XBRL-CONF-CR1-2005-04-25.zip
Unzip the latter into a {ROOT} directory to create a directory hierarchy. Open the file {ROOT}/xbrl.xml in a browser. This yields a hypertext navigable tree view of test set lists, and a test list in each set of tests.
Editors
|
Name |
Contact |
Affiliation |
|
Walter Hamscher |
Standard Advantage |
|
|
Ron van Ardenne |
J2R BV – Batavia XBRL |
|
|
Hugh Wallis |
Standard Dimensions |
Abstract
XBRL is the specification for the eXtensible Business Reporting Language. XBRL allows software vendors, programmers, intermediaries in the preparation and distribution process and end users who adopt it as a specification to enhance the creation, exchange, and comparison of business reporting information. Business reporting includes, but is not limited to, financial statements, financial information, non-financial information, general ledger transactions and regulatory filings, such as annual and quarterly reports.
This document describes a set of conformance tests for XBRL 2.1 Processors as defined in the XBRL 2.1 Specification Recommendation [XBRL]. Unless indicated otherwise, references to ‘XBRL’ and ‘the specification’ in this document mean ‘XBRL 2.1’ and ‘the XBRL 2.1 specification recommendation’, respectively.
Status of this document
Circulation of this Candidate Recommendation is unrestricted. This document and the associated conformance suite test files are a Candidate Recommendation that was approved by the International Steering Committee on 2005-04-25. Recipients of this Candidate Recommendation are invited to submit comments to the editor and authors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of contents
2 Changes from the previous recommendation
4.1 Schema Minimal Conformance
5.1 Linkbase Minimal Conformance
5.2 PTVLI to demonstrate Linkbase Full Conformance
6.1 Instance Minimal Conformance
6.2 PTVI to demonstrate Instance Full Conformance
7.2 Structure of Testcase Files
7.3 PTVx reference from Testcase Files
7.4 When to generate PTVx files
7.6 Contents of a tricky variation
Document history and acknowledgments (non-normative)
Intellectual property status (non‑normative)
Appendix: Approval process (non-normative)
List of Figures
Figure 1. The conformance suite tests an XBRL Processor.
Figure 2. A minimally conforming processor is needed to test XBRL producers.
Figure 3. Before and after XBRL validation (post taxonomy validation linkbase infoset)
Figure 4. Before and after validation (post taxonomy validation infoset)
Figure 5. Fragment of the root file xbrl.xml
Figure 6. A testcase consists of one or more variations
Figure 7. PTVx reference from testcase files.
Figure 8. The variation “SchemaRefXMLBase” in testcase “SchemaRef”
Figure 9. The file base/SchemaRefTrickyExample.xsd
Figure 10. The schema SchemaRefTrickyExample.xsd
Figure 11. The instance SchemaRefXMLBase.xml
1 Introduction
XBRL is the specification for the eXtensible Business Reporting Language. XBRL allows software vendors, programmers and end users to enhance the creation, exchange, and comparison of business reporting information. Business reporting includes, but is not limited to, financial statements, financial information, non-financial information and regulatory filings such as annual and quarterly financial statements.
This document describes the conformance suite for XBRL Processors including PTVI and PTVLI files (Post-Taxonomy Validation Infoset and Post-Taxonomy Validation Linkbase Infoset).
The PTVx files are referred to as Infosets and not Instances or Linkbases because they are not Instances or Linkbases in the XBRL sense of those words. Extended details on technical issues regarding testcases and PTVx files can be found in section 7.
1.1 Purpose
The purpose of the conformance suite is to facilitate interoperable XBRL processor implementations. XBRL documents (taxonomies and instances) produced by an XBRL conformant application should be consumable directly by a different XBRL conformant processor without loss of information.
The conformance suite is normative in the same sense that the specification [XBRL] is normative; an application is an XBRL Processor if and only if it passes all of the conformance suite tests. There are different levels of conformance:
Minimal Conformance: Processors correctly distinguish between syntactically valid and invalid XBRL. Validity with respect to W3C XML Schema is not sufficient to determine XBRL validity; additional syntactic restrictions apply.
Full Conformance: Processors correctly derive the semantic consequences of XBRL documents and produce complete and correct inferences from a set of input documents. These inferences are captured in two types of output:
· PTVLI (Post-Taxonomy Validation Linkbase Infosets) in which the linkbases are transformed to produce the result of href dereferencing and prohibition that can be made by processing
o linkbases in the DTS.
· PTVI (Post-Taxonomy Validation Infosets) in which instances are transformed to include the result of inferences that can be made by processing
o the instance,
o linkbases and schemas in the DTS.
The conformance suite marks each test to indicate whether it is necessary for minimal or full Conformance. See sections 7.3 and 7.4 for details.
Figure 1 and Figure 2 show the relationship between the conformance suite and the testing of XBRL applications that produce XBRL.
Figure 1 shows that XML-Valid input documents are consumed by the application being tested. The results consist of indicators as to whether the inputs are valid XBRL, and in many cases for full Conformance, either a PTVL or PTVI. If all outputs match then the processor is conformant.
In Figure 2, an XBRL application (which does not itself need to be an XBRL Processor) produces candidate XBRL documents that are tested for XML Schema validity and if they pass, are then tested by an XBRL Processor for XBRL validity. A minimally conforming XBRL Processor is a logical prerequisite for this type of testing; a fully conforming XBRL Processor would be able to detect other semantic inconsistencies in the document.
Figure 1. The conformance suite tests an XBRL Processor.
Figure 2. A minimally conforming processor is needed to test XBRL producers.
1.2 Scope
Testing of applications that consume XBRL (Figure 1) is included in the scope of this conformance suite.
Testing of applications that produce XBRL (Figure 2) is not within the scope of this conformance suite.
The XBRL 2.1 specification recommendation is in scope. Other work products of XBRL International, whether public or internal, are not in scope. XBRL is based on XML Schema [SCHEMA-0] [SCHEMA-1] [SCHEMA-2]. The conformance suite generally contains at least one test for each appearance in the specification of ‘MUST’ (and of ‘fatal error’ and ‘error’ which are akin to ‘MUST’) that are not already enforced by XML Schema validation.
There are differences in the way that different vendors’ XML Schema validation components interpret the W3C XML Schema specification. The scope of this conformance suite encompasses only Xerces and .NET parser implementations. However, at this time all conformance test files are common to both. Where there have been differences concerning interpretations such as namespaces, import elements, and schema locations, the XBRL 2.1 Specification itself has been modified so as to allow a common set of files to represent the conformance suite.
1.3 Terminology
The terminology used in XBRL frequently overlaps with terminology from other fields, and the following list is provided to reduce the possibility of ambiguity and confusion. For definitions of the following terms see the XBRL 2.1 Specification [XBRL].
· abstract element, alias concept, alias item, c‑equal, child, parent, sibling, grandparent, uncle, ancestor, concept, concrete element, CWA, duplicate items, duplicate tuples, element, entity, error, essence concept, essence item, fatal error, instance namespace, item, least common ancestor, linkbase namespace, must, must not, required, shall, shall not, should, should not, may, optionaL, non-numeric item, numeric item, period, p‑equal, s‑equal, taxonomy, tuple, u-equal, v‑equal, XBRL instance, x‑equal.
1.4 Documentation conventions
The following highlighting is used to present literal code fragments:
|
|
The following highlighting is used for non-normative examples:
|
|
Non-normative editorial comments are denoted as follows, and will be removed from the final recommendation:
WH: This highlighting is used to indicate editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
2 Changes from the previous recommendation
Previous: XBRL-CONF-PWD-2003-12-31.doc
- Extended on subject of PTVx, see sections 1.1, 5.2, 6.2, 7.2 to 7.5
- Updated samples/figures for PTVx see sections 5.2 and 6.2
3 Overview of the tests
The structure of the test suite is based on the OASIS XSL Conformance Suite. In the case of XSL the structure of each individual test is simple:
· An input .xml file;
· An .xsl style sheet;
· An expected output .txt file and its location.
In the OASIS suite, sets of files are then organised into individual “variants” in a list comprising a “test case” and then the test cases are organised into a list. XML files are used to represent the individual tests and relationships among the files. Implementers develop their own test harness, which uses these XML files to successively apply each .xsl file to each .xml file and compare the result to the output .txt file (after running both through infoset.xsl in order to remove irrelevant output differences). In each case the input may either be valid or invalid, and the test harness produces a report showing the pass/fail status of the implementation on each test. In general, a test harness does not stop at the first failure but attempts to perform all of the tests.
The three main sets of tests for XBRL conformance are Schema, Linkbase and Instance tests. The objectives of each are described at a high level in this document. To see the tests themselves, unzip the package and visit the {ROOT}/xbrl.xml file. In general each test may have zero or more of these different types of file:
· Schema: CamelCase style file name, suffix .xsd;
· Linkbase: CamelCase style file name, suffix .xml;
· Instance: CamelCase style file name, suffix .xml;
· Result: CamelCase style file name ending with Out and file suffix .xml when a PTVLI or PTVI is needed either for linkbase or instance tests.
Extended details on technical issues regarding testcases and PTVx files can be found in section 7.
4 Schema test objectives
All Schema tests assume that no XBRL processing take place until the .xsd file has itself been parsed and XML Schema-Validated without errors.
The attribute xml:base is ignored when processing xsi:schemaLocation, hence there are no tests for that.
4.1 Schema Minimal Conformance
The overall objectives of the schema Minimal Conformance tests are:
1. Ensure that the XBRL instance namespace is not in an include element;
2. Detect misuse of the periodType attribute;
3. Ensure that each item type has simpleContent unless derived from fractionItemType;
- Ensure that “any,” “anyAttribute,” anonymous types, the mixed attribute, and group constructs are not used in tuple definitions.
4.2 Schema Full Conformance
There are no Schema-only tests for Full Conformance.
5 Linkbase test objectives
The Linkbase tests assume that no XBRL processing take place until the .xsd and .xml input files have been parsed without errors.
5.1 Linkbase Minimal Conformance
The objectives of the linkbase Minimal Conformance tests are as follows:
1. Ensure that the processor correctly processes all of the linkbaseRef elements appearing in a schema so as to find all linkbases of all kinds in the taxonomy;
2. Ensure that the processor processes the xml:base attribute correctly in linkbaseRef elements;
3. Ensure that the processor enforces the constraint inherent in [XBRL] Table 8 that the role of the linkbaseRef element must correspond to linkbases containing only certain kinds of extended-type links;
4. Ensure that all locator elements resolve their href attributes to an XML Schema element element or an element that is a resource-type;
5. Ensure that xpointer syntax in linkbase href attributes resolves correctly;
6. Ensure the processor processes occurrences of the xml:base attribute correctly when resolving href attributes in locators;
7. Ensure that no two arcs in an extended-type link have the same “from” and “to” XLink label values even if their arcrole values differ (this is an XLink syntax constraint). Note that the “from” and “to” concepts may be the same as long as they are denoted by locator elements having different XLink labels;
8. Ensure that the discoverable taxonomy set containing the namespace http://www.xbrl.org/2003/instance is identical to that reachable via href and schema linkbaseRef elements;
9. Detect violations of the arc role cycle constraints for built-in arc roles (test must include detection of overridden arcs) (and must also test whether arcs appear in extended-type links with the same roles or with different roles);
10. Detect undeclared roles appearing on extended-type links;
11. Detect undeclared URI appearing in the preferredLabel attribute of presentation arcs;
12. Detect undeclared arc roles;
13. Detect violations of the arc role cycle constraints for declared arc roles (considering overridden arcs and roles).
14. Detect violations of the constraints among the balance attribute and calculation summation‑item arcs as documented in Table 5 of section 5.1.1.2 [XBRL].
5.2 PTVLI to demonstrate Linkbase Full Conformance
The objective of the linkbase Full Conformance test is for a XBRL processor to demonstrate that it can
· derive a complete and consistent graph for every arc role it finds via a process of discovery and linkbase processing including applying the rules of prohibiting and overriding relationships.
Demonstration of full conformance is done by creating and comparing PTVLI files. Extended details on technical issues regarding testcases and PTVx files can be found in section 7.
A PTVLI is a ptvl element with an xsi:schemaLocation for namespace http://www.xbrl.org/2003/ptv that refers to the ptv-2003-12-31.xsd in the lib directory of the conformance suite and defaults to that namespace and whose content is a sequence of arc elements in which:
· The arcs which are included in the networks of arcs in the DTS after applying the rules of prohibiting and overriding relationships on all arcs from all linkbases in the DTS.
PTVLI files are to be sorted:
· The PTVLI is canonical in the sense that within each child element of the root, the attributes are sorted lexicographically, and then those elements are sorted lexicographically with respect to the element names and attribute values.
Each arc present in the PTVLI file is to be converted from its original representation to PTVLI representation as ptv:arc and contains:
· An arcRole attribute with a value that equals the xlink:arcrole value on the original arc,
· An extRole attribute with a value that equals the xlink:role value on the extended‑type link from which the original arc originates,
· A fromPath attribute with a value that equals a converted xlink:href value of which a uri part of the xlink:href attribute value on that loc element the xlink:from of the original arc refers to is converted to the uri of the targetnamespace for the element referred by the xlink:href value,
· when the xlink:to of the original arc refers to a label resource: a labelLang attribute with a value that equals xml:lang value on the original arc,
· A linkType attribute with a value that equals
o label when the extended-type link from which the original arc originates is a labelLink.
o reference when the extended-type link from which the original arc originates is a referenceLink.
o definition when the extended-type link from which the original arc originates is a definitionLink.
o presentation when the extended-type link from which the original arc originates is a presentationLink.
o calculation when the extended-type link from which the original arc originates is a calculationLink.
· An order attribute with a value that equals the order on the original arc, or the default value 1 when the original arcs does not have a order attribute,
· When the xlink:to of the original arc refers to a resource element: a resRole attribute with a value that equals the xlink:role on that resource,
· In case the xlink:to of the original arc refers to a loc element a toPath attribute with a value that equals a converted xlink:href value of which a uri part of the xlink:href attribute value on that loc element is converted to the uri of the targetnamespace for the element referred by the xlink:href value,
· When the original arc is a summation‑item arc: a weight attribute with a value that equals the weight on the original arc,
· In case the xlink:to of the original arc refers to a resource element: a value for the arc element that equals
o The content of the referenced resource‑type element.
Figure 3. Before and after XBRL validation (post taxonomy validation linkbase infoset)
|
Before XBRL validation: |
|
<linkbase xmlns="http://www.xbrl.org/2003/linkbase" xmlns:xbrll="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.xbrl.org/2003/linkbase ../lib/xbrl-linkbase-2003-12-31.xsd"> <calculationLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link"> <loc xlink:type="locator" xlink:href="209-01-DifferentWeights.xsd#ItemCredit" xlink:label="ItemCredit"/> <loc xlink:type="locator" xlink:href="209-01-DifferentWeights.xsd#SumCredit" xlink:label="SumCredit"/> <calculationArc xlink:type="arc" xlink:from="ItemCredit" xlink:to="SumCredit" weight="1" xlink:arcrole= "http://www.xbrl.org/2003/arcrole/summation-item" priority="0"/> </calculationLink> <calculationLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link"> <loc xlink:type="locator" xlink:href="209-01-DifferentWeights.xsd#ItemCredit" xlink:label="ItemCredit"/> <loc xlink:type="locator" xlink:href="209-01-DifferentWeights.xsd#SumCredit" xlink:label="SumCredit"/> <calculationArc xlink:type="arc" xlink:from="ItemCredit" xlink:to="SumCredit" weight="0.5" xlink:arcrole= "http://www.xbrl.org/2003/arcrole/summation-item" priority="0"/> </calculationLink> </linkbase>
|
|
PTVLI after validation: |
|
<ptvl xmlns="http://www.xbrl.org/2003/ptv" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.xbrl.org/2003/ptv ../../lib/ptv-2003-12-31.xsd"> <arc linkType="calculation" extRole="http://www.xbrl.org/2003/role/link" arcRole="http://www.xbrl.org/2003/arcrole/summation-item" fromPath="http://mycompany.com/xbrl/arcs#ItemCredit" toPath="http://mycompany.com/xbrl/arcs#SumCredit" order="1" weight="1"/> <arc linkType="calculation" extRole="http://www.xbrl.org/2003/role/link" arcRole="http://www.xbrl.org/2003/arcrole/summation-item" fromPath="http://mycompany.com/xbrl/arcs#ItemCredit" toPath="http://mycompany.com/xbrl/arcs#SumCredit" order="1" weight="0.5"/> </ptvl>
|
The schema defining the ptvl element is provided in the zip file as ptv-2003-12-31.xsd.
6 Instance test objectives
The Instance tests assume that no XBRL processing take place until the .xsd and .xml input files have been parsed without errors.
Determine whether the set of .xsd schema, .xml linkbases and an instance are syntactically correct by checking features and constraints detected neither by XML Schema validation nor XBRL validation of the taxonomy schema and linkbases alone.
6.1 Instance Minimal Conformance
The objective of the instance Minimal Conformance tests are as follows:
1. Ensure that all schemaRef elements refer to schemas;
2. Ensure that the processor processes the xml:base attribute correctly in schemaRef elements;
3. Ensure that every item refers to a context with an id attribute within the scope of the same xbrl element (the anonymous element instances defined in test‑2003‑12‑31.xsd is used to “wrap” multiple input instances).
4. Ensure that every item refers to a unit with an id attribute within the scope of the same xbrl element;
5. Ensure that each footnote href dereferences to an element within the scope of the same xbrl element;
6. Ensure that no element descendants (not just children, but all descendants) of segment or scenario are in any XBRL namespaces;
7. The start dateTime must precede the end dateTime;
8. Ensure that every item refers to a context whose period element is consistent with the item’s periodType attribute;
9. Ensure that the unit of measure constraints among monetary, shares, pure and other data types are enforced;
10. Ensure that all measures are expressed in minimal form, e.g., feet / feet is not legal;
11. Because some XML Schema validators do not enforce it, ensure that each measure is a QName found in a known schema;
12. Ensure that every numeric item has either decimals or precision but not both;
13. Ensure that that required items as indicated by the requires arc role are present (irrespective of the value of the role attribute);
14. Ensure that equivalent arcs are detected correctly for prohibition;
15. Detect duplicated or inconsistent arcs in presentation, definition and calculation linkbases.
6.2 PTVI to demonstrate Instance Full Conformance
The objective of the Instance Full Conformance test is for a XBRL processor to demonstrate that it can
· check if an instance does not violate essence-alias relationships in the DTS,
· calculate the correct values for summation facts based on summation-item relationships in the DTS,
· infer precision from decimals and a given numeric value,
· resolve concepts from the DTS on which facts are reported in the instance,
· resolve contexts and their period from the instance for which facts are reported in the instance.
Demonstration of full conformance is done by creating and comparing PTVI files. Extended details on technical issues regarding testcases and PTVx files can be found in section 7.
The PTVI of a validated instance is an xbrl element with a xsi:schemaLocation for namespace http://www.xbrl.org/2003/ptv that refers to the ptv-2003-12-31.xsd in the lib directory of the conformance suite and prefixes that namespace with ptv and whose content is:
· all schemaRef elements copied from the original instance,
· followed by all unit elements copied from the original instance,
· followed by all context elements copied from the original instance,
· followed by all tuple elements copied from the original instance,
· followed by the following facts:
o all facts from the original instance,
o The most precise facts possible by closure of all discoverable essence-alias arcs. Infer any essence item fact that is not present in the original instance. The essence item facts that are inferred must have the same value as the alias item facts in the original instance,
o NOTE: Not included are the optional inferred item values that could be inferred by closure of the summation‑item arcs in the PTVL of calculation arcs in the DTS.
PTVI files are to be sorted:
· Each set of elements is lexicographically sorted within its type;
· Element children of a tuple remain in their original order, because XBRL does not allow the all compositor and therefore the order of appearance of elements is already determined by XML Schema validation.
Each Fact present in the PTVI file is to be converted to PTVI representation and contains:
· The contextRef attribute that is copied from the original Fact,
· The precision attribute that is copied from the original Fact or that is inferred form the decimals attribute from the original Fact. Facts in PTVI files must not have a decimals attribute. Facts that do not have precision or decimals attribute in the original instance (fractions, tuples) do not have a precision attribute in their PTVI representation
· The ptv:balance attribute with the value form the xbrli:balance attribute on the Concept in the DTS on which the original Fact is reported. Facts in the original instance that are reported on Concepts in the DTS that do not have a xbrli:balance attribute do not have a ptv:balance attribute in their PTVI representation,
· The ptv:periodType attribute with the value
o instant when the context for the original Fact has a xbrli:instant element in its xbrli:period element or
o duration when the context for the original Fact has a xbrli:forever, or xbrli:startDate and xbrli:endDate element in its period element.
· The unitRef attribute that is copied from the original Fact,
· Attributes from the original Fact other than those explicitly named here (such as xmlns and id) do not appear in the PTVI Fact.
Figure 4. Before and after validation (post taxonomy validation infoset)
|
Instance before taxonomy validation (schema and linkbases not shown): |
|
<xbrl xmlns="http://www.xbrl.org/2003/instance" xmlns:link="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:example="http://example.com/xbrl/taxonomy/EssenceAlias" xmlns:iso4217="http://www.xbrl.org/2003/iso4217" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://example.com/xbrl/taxonomy/EssenceAlias EssenceAlias.xsd"> <link:schemaRef xlink:href="EssenceAlias.xsd" xlink:type="simple"/> <example:TaxExpense contextRef="c1" unitRef="u1" precision="3" >100</example:TaxExpense> <context id="c1"> <entity> <identifier scheme="www.example.com">example</identifier> </entity> <period> <instant>2003-03-31</instant> </period> </context> <unit id="u1"> <measure>iso4217:USD</measure> </unit> </xbrl>
|
|
PTVI After taxonomy validation: |
|
<xbrl xmlns="http://www.xbrl.org/2003/instance" xmlns:link="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink" |