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	walter@hamscher.com	Standard Advantage
Ron van Ardenne	ron.van.ardenne@j2r.nl	J2R BV – Batavia XBRL
Hugh Wallis	hugh@standarddimensions.com	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.

Editors. 1

Abstract 1

Status of this document 1

1.4 Documentation conventions 7

2 Changes from the previous recommendation. 7

3 Overview of the tests. 8

4 Schema test objectives. 9

4.1 Schema Minimal Conformance 9

4.2 Schema Full Conformance 9

5 Linkbase test objectives. 9

5.1 Linkbase Minimal Conformance 9

5.2 PTVLI to demonstrate Linkbase Full Conformance 10

6 Instance test objectives. 13

6.1 Instance Minimal Conformance 13

6.2 PTVI to demonstrate Instance Full Conformance 14

7 Technical details. 17

7.1 Directory Structure 17

7.2 Structure of Testcase Files 18

7.3 PTVx reference from Testcase Files 20

7.4 When to generate PTVx files 21

7.5 How to verify PTVx files 22

7.6 Contents of a tricky variation 22

7.7 How to submit tests 23

8 References. 24

Document history and acknowledgments (non-normative). 24

Intellectual property status (non‑normative). 25

Appendix: Approval process (non-normative). 25

List of Figures

Figure 1. The conformance suite tests an XBRL Processor. 5

Figure 2. A minimally conforming processor is needed to test XBRL producers. 6

Figure 3. Before and after XBRL validation (post taxonomy validation linkbase infoset) 12

Figure 4. Before and after validation (post taxonomy validation infoset) 16

Figure 5. Fragment of the root file xbrl.xml 18

Figure 6. A testcase consists of one or more variations 19

Figure 7. PTVx reference from testcase files. 20

Figure 8. The variation “SchemaRefXMLBase” in testcase “SchemaRef” 22

Figure 9. The file base/SchemaRefTrickyExample.xsd. 23

Figure 10. The schema SchemaRefTrickyExample.xsd. 23

Figure 11. The instance SchemaRefXMLBase.xml 23

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">

xlink:type="simple"/>

<example:TaxExpense contextRef="c1"

unitRef="u1"

precision="3" >100</example:TaxExpense>

<identifier scheme="www.example.com">example</identifier>

</entity>

</period>

</context>

</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"

xmlns:example="http://example.com/xbrl/taxonomy/EssenceAlias"

xmlns:iso4217="http://www.xbrl.org/2003/iso4217"

xmlns:ptv="http://www.xbrl.org/2003/ptv"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://example.com/xbrl/taxonomy/EssenceAlias ../EssenceAlias.xsd

http://www.xbrl.org/2003/ptv ../../lib/ptv-2003-12-31.xsd">

</unit>

<identifier scheme="www.example.com">example</identifier>

</entity>

</period>

</context>

<example:TaxExpense contextRef="c1"

unitRef="u1"

precision="3"

ptv:balance="debit"

ptv:periodType="instant">100</example:TaxExpense>

</xbrl>

7 Technical details

7.1 Directory Structure

The conformance suite has a hierarchical tree structure:

· {ROOT}

o Common – all tests common to all platforms are here.

§ Lib – the directory where the core XBRL and supporting schemas are found. At the moment the latest date embedded in the file names is 2003‑12-31.

§ Schema – directory where all the Schema tests are. Within this directory there are two categories of file:

· Testcase files, whose file names begin with a three-digit number followed by “-“ and a lower case letter and whose suffix is .xml;

· Test files which in this directory are all .xsd files. The prefix consists of the testcase three-digit number followed by “-“ and a two-digit variation number.

§ Linkbase – directory where all the Linkbase tests are. No distinction is made in this directory between Minimal and Full conformance tests. There are four types of file:

· Testcase files, whose file names begin with a three-digit number followed by “-“ and a lower case letter and whose suffix is .xml;

· Test files which in this case may be either schemas (.xsd) or linkbases (.xml). The prefix consists of the testcase three-digit number followed by “-“ and a two-digit variation number.

· A base subdirectory with testcase and test files needed specificall to test the xml:base attribute.

· An out subdirectory where are stored the “gold standard” PTVx files which Full Conformance tests require.

§ Instance – directory where all the Instance tests are. No distinction is made in this directory between Minimal and Full conformance tests. There are five types of file:

· Testcase files, whose file names begin with a three-digit number followed by “-“ and a lower case letter and whose suffix is .xml;

· Test files which in this case may be schemas (.xsd), linkbases (.xml), or instances (.xml). The prefix consists of the testcase three-digit number followed by “-“ and a two-digit variation number.

· A base subdirectory with testcase and test files needed specifically to test the xml:base attribute.

· An out subdirectory where are stored the the “gold standard” PTVx files which some Full Conformance tests require.

o DotNet – tests only relevant to .NET environments. It is currently empty.

o Java – tests relevant only in Java environments. It is currently empty.

7.2 Structure of Testcase Files

The numbering scheme is a code in the form “Tsu-vv” where T is 1, 2, or 3 depending on whether the test is a schema, linkbase or instance test respectively, and where “s” is a series that is 0, 1, 2 etc. if the testcase is part of the minimal suite, and 8 or 9 otherwise. The variations within a testcase number from 01. Examples:

· 101-01 – a schema test, the first variation (-01) of the first testcase (01).

· 294-05 – the 5^th variation in a linkbase test for full conformance which is the 4^th testcase of its kind.

Note that the numbering is not entirely consistent in that usually the files pertaining to a given variation all have the prefix of that variation; but sometimes, particularly in the linkbase tests, files are shared in which case they have no numeric prefix.

The root file of the tests suites is xbrl.xml. A portion of it is shown in the figure below.

Figure 5. Fragment of the root file xbrl.xml

<testcases name="XBRL 2.1 Tests" contributor ="Joe Tester" company="Test & Co." date="10/23/2003">

<testcase uri="Common/instance/301-idScope.xml"/>

</testcases>

The testcases element has the following attributes:

· name: a brief name for the test cases taken as a whole.

· contributor: name of the individual responsible.

· company: company of the individual responsible.

· date: date the test was published.

The testcases element may contain any number of testcase elements. Each of these has only one attribute:

· uri: the relative URI where the testcase file itself is to be found.

There is no schema for the testcases element.

The structure of a testcase file is described by the schema CONF/Common/lib/test.xsd. The figure below shows one testcase and its first two variations. The testcase is not meant to be directly executed; it is meant only as a declarative representation that organise the information in a way that programs (specifically, a test harness) can use.

Figure 6. A testcase consists of one or more variations

<testcase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Identifier Scope"

description="Section 4.3 The Item Element" outpath="out" owner="joe.tester@some.com"

xsi:noNamespaceSchemaLocation="../lib/test.xsd" minimal="false">

<variation id="V-01" name="PeriodInstantValid">

<description>

303.01 instant context and item defined with PeriodType="instant"

</description>

<data>

<xsd readMeFirst="false">Period.xsd</xsd>

<instance readMeFirst="true">303-01-PeriodInstantValid.xml</instance>

</data>

<result expected="valid">303-01-PeriodInstantValidOut.xml</result>

</variation>

<variation id="V-03" name="PeriodInstantInValid">

303.03 duration context and item defined with PeriodType="instant"

</description>

<data>

<xsd readMeFirst="false">Period.xsd</xsd>

<instance readMeFirst="true">303-03-PeriodInstantInvalid.xml</instance>

</data>

</variation>

</testcase>

The testcase element has the following attributes

· name: a brief name for test cases.

· description: usually a reference to the portion of the Specification text itself that supports the need for the test.

· outpath: the pathname, relative to the directory where the test data is stored, where the output corresponding to the test may be found.

· owner: the e-mail address of the main contact for this testcase.

· minimal: (optional, default value true) indicates whether the testcase is part of the minimal conformance suite. If false, it means the testcase is only part of the full conformance suite.

The testcase may contain any number of variations. Each variation has the following parts:

· name (attribute): a brief name for the variation.

· id (attribute): an identifier used to ensure uniqueness within the testcase.

· description element: a text explanation of what syntactic constraint or other feature is meant to be tested by this variation.

· xsd, linkbase, and instance elements: these elements give the relative pathname of the input files to the XBRL processor for this specific variation. Schema tests will only contain xsd elements; Linkbase tests contain both xsd and linkbase elements; Instance tests contain all three.

o The readMeFirst attribute is a Boolean that signals which of the several input files is actually the one that the XBRL Processor should read in order to begin processing.

· result elements: these elements declare the expected result of the variation, either valid or invalid (indicated by the “expected” attribute). Also, in the case of the full conformance test, the content of the element the relative pathname of a PTVLI or PTVI against which the XBRL processor output should be compared (assuming that the output has already been established to pass minimal conformance).

o The expected attribute is either “valid” or “invalid”. This refers to XBRL validity. All files are XML Schema-valid.

There are XSL stylesheets testcase.xsl and testcases.xsl in the directory CONF that allow browsers to view the contents of testcase files in tabular form.

7.3 PTVx reference from Testcase Files

Testcase variations are declared in the testcase files for the XBRL 2.1 Conformance Suite 1.0. The testcase and its variations contain the directions for XBRL Processors when to generate which PTVx files and directions for test applications which reference PTVx files to use for verification regarding passing or failing full conformance tests.

Figure 7. PTVx reference from testcase files.

303.01 instant context and item defined with PeriodType="instant"

</description>

<data>

<xsd readMeFirst="false">Period.xsd</xsd>

<instance readMeFirst="true">303-01-PeriodInstantValid.xml</instance>

</data>

<result expected="valid">303-01-PeriodInstantValidOut.xml</result>

</variation>

303.03 duration context and item defined with PeriodType="instant"

</description>

<data>

<xsd readMeFirst="false">Period.xsd</xsd>

<instance readMeFirst="true">303-03-PeriodInstantInvalid.xml</instance>

</data>

</variation>

</testcase>

Each testcase has the following relevant parts concerning PTVx files:

· testcase element: This element has a boolean value for the minimal attribute. The value true indicates that the testcase only tests minimal conformance. The value false indicates that the testcase tests full conformance and that PTVx files can be part of the variations.

Each variation has the following relevant parts concerning PTVx files:

· xsd, linkbase, and instance elements: these elements give the relative pathname of the input files to the XBRL processor for this specific variation.

o The readMeFirst attribute is a Boolean that signals which of the several input files is actually the one that the XBRL Processor should read in order to begin processing. When the readMeFirst attribute on an xsd or linkbase element has the value true the variation can make use of a PTVLI file. When the readMeFirst attribute on an instance element has the value true the variation can make use of a PTVI file.

o result elements: these elements declare the expected result of the variation, either valid or invalid (indicated by the “expected” attribute). Also, in the case of the full conformance test, the value of the element declares the filename of a PTVLI or PTVI in the out subdirectory against which the XBRL processor output should be compared by a test application.

o The expected attribute is either “valid” or “invalid”. This refers to XBRL validity. Only valid testcase variations reference PTVx files.

7.4 When to generate PTVx files

PTVLI files are to be created by a XBRL Processor that runs a Conformance Suite testcase variation when all these conditions apply:

· The testcase has the value false for the minimal attribute on the testcase element.

· The variation has the value valid for the expected attribute on the result element.

· The variation has the value true for the readMeFirst attribute on an xsd or linkbase element.

· The variation has a value for the result element that indicates the location of a reference file in the out subdirectory.

PTVI files are to be created by a XBRL Processor that runs a Conformance Suite testcase variation when all these conditions apply:

· The testcase has the value false for the minimal attribute on the testcase element.

· The variation has the value valid for the expected attribute on the result element.

· The variation has the value true for the readMeFirst attribute on an instance element.

· The variation has a value for the result element that indicates the location of a reference file in the out subdirectory.

7.5 How to verify PTVx files

To demonstrate the full conformance of a XBRL Processor a test application has to confirm that al the PTVx files, which should be generated according to the found conditions in the testcase variations, were actually generated and verified.

The test application has to confirm that all the generated PTVx files are successfully verified with the contents of the reference PTVx files that are declared in the appropriate testcase variations.

To be able to compare only the relevant content of the PTVx files these files are to be transformed with the xbrl-infoset.xsl stylesheet that is located in the root of the Conformance Suit distribution.

To confirm a verified verdict on a testcase variation a test application has to

· Conclude that the testcase variation meets the conditions for PTVx generation,

· locate the generated PTVx file,

· locate the reference PTVx file,

· transform both PTVx files with the xbrl-infoset.xsl stylesheet to sorted sequences of relevant elements and attributes that are found in the PTVx files,

· conclude that the character sequence of the transformed generated PTVx file is equal to the character sequence of the transformed reference file.

7.6 Contents of a tricky variation

An example of a tricky variation is the “307-03-SchemaRefXMLBase” variation in the testcase 307‑SchemaRef. The goal of this specific variation is to ensure that the xml:base attribute is processed correctly. The way to do this is to ensure that the processor will detect that it is invalid only if it actually processes xml:base. Figure 8 below shows the variation declaration itself. Notice that the relative pathnames of one of the input xsd files places it into a subdirectory of where the XSD file would normally be.

Figure 8. The variation “SchemaRefXMLBase” in testcase “SchemaRef”

<data>

<linkbase readMeFirst="false">base/SchemaRefTrickyExample.xsd</linkbase>

<xsd readMeFirst="false">SchemaRefTrickyExample.xsd</xsd>

<instance readMeFirst="true">307-03-SchemaRefXMLBase.xml</instance>

</data>

</variation>

The figure below shows all three files. Notice that base/SchemaRefTrickyExample.xsd is really not a schema at all… but the file of the same name in the same directory is in fact a schema. Therefore, if the processor does the right thing with the xml:base attribute then it will detect the error -- hence the expected attribute of the result element is “invalid”. Otherwise it will not detect that it is invalid.

Figure 9. The file base/SchemaRefTrickyExample.xsd

<linkbase

xmlns="http://www.xbrl.org/2003/linkbase"

xmlns:xl="http://www.xbrl.org/2001/XLink"

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"

xml:base="../../schema">

<label xlink:type="resource" xlink:label="aaaLabel" xlink:title="aaa Title" xlink:role="http://www.xbrl.org/2003/role/label" xml:lang="en">Retained Earnings</label>

</labelLink>

</linkbase>

Figure 10. The schema SchemaRefTrickyExample.xsd

<xsd:schema targetNamespace="http://anothercompany.com/xbrl/taxonomy"

xmlns:xbrli="http://www.xbrl.org/2003/instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://mycompany.com/xbrl/taxonomy">

<xsd:import namespace="http://www.xbrl.org/2003/instance"

schemaLocation="../lib/xbrl-instance-2003-12-31.xsd"/>

<xsd:element name="doNotSeeMe"

type="xbrli:monetaryItemType"

substitutionGroup="xbrli:item" id="a1"

xbrli:periodType="duration"/>

<xsd:element name="doNotLookHere"

type="xbrli:monetaryItemType"

substitutionGroup="xbrli:item" id="a2"

xbrli:balance="debit"

xbrli:periodType="instant"/>

</xsd:schema>

Figure 11. The instance SchemaRefXMLBase.xml

<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:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="

http://www.xbrl.org/2003/instance

../lib/xbrl-instance-2003-12-31.xsd"

xml:base="./base/">

</xbrl>

The file marked with readMeFirst="true" (be it a schema, linkbase or instance) when read by the XBRL processor in a test harness, must produce a result of either “invalid”, “valid” or “valid” along with a PTVL (if it was a linkbase) or PTVI (if it was an instance).

7.7 How to submit tests

If you are going to submit new or updated test cases or variations, please do so as follows.

Unzip the entire test suite directory structure onto your machine into a {ROOT} directory.
Make your modifications.
Create a Zip file whose root is {ROOT}, just like the distribution Zip archive.
Add to the Zip archive ONLY your modified files.
Email the resulting Zip file to spec@xbrl.org with “XBRL 2.1 Conformance Suite Update” in the subject line.

8 References

[SCHEMA-0]	World Wide Web Consortium.
	XML Schema Part 0: Primer.
	http://www.w3.org/TR/xmlschema-0/

[SCHEMA-1]	World Wide Web Consortium.
	XML Schema Part 1: Structures.
	http://www.w3.org/TR/xmlschema-1/

[SCHEMA-2]	World Wide Web Consortium.
	XML Schema Part 2: Datatypes.
	http://www.w3.org/TR/xmlschema-2/

[XBRL]	Philip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon and Hugh Wallis
	Extensible Business Reporting Language (XBRL) 2.1 Specification
	http://www.xbrl.org/2003/XBRL-RECOMMENDATION-2003-12-31.doc

Document history and acknowledgments (non-normative)

This conformance suite was written with the contribution of many people, particularly the participants of the XBRL Specification Working Group. The XBRL International Specification Group is chaired by Masatomo Goto, Fujitsu Laboratories of USA, and its vice chair is Hugh Wallis of Hyperion Solutions Corporation. Adam Greissman, a consultant to XBRL International Inc., coordinated the voluntary development activities on the test cases and variations.

2003-05-29	Hamscher	First draft of document prepared and distributed.
2003-07-18	Hamscher	Second draft of document prepared and distributed following proposed revisions to the 2003-05-16 specification PWD.
2003-07-21	Hamscher	Changed terminology to Minimal conformance versus Full conformance. Updated figures to conform to PTVL / PTVI terminology. Reorganised tests in test suite, added references to file names in the test suite, and added additional tests to complete the set.
2003-07-22	Hamscher	Added tests relating to schemaRef and other additions made during Toronto meeting. Repaired the PTVL to take account of the fact that concepts are actually defined by their location (locator) and not by namespace and element.
2003-07-26	Hamscher	Added explanation of the structure and usage of testcase files. Changed all tests in the suite to use -2003‑07‑22 extensions (although these files continue to change).
2003-07-29	Hamscher	Added the inferSummation tests, the “instances” element, and instructions on how to submit updates for test authors.
2003-08-02	Hamscher	Integrated tests from multiple authors, introduced testcase and variation numbering scheme. Fixed all files to work with 2003‑07‑31 public working draft XBRL schemas.
2003-12-29	Hamscher	Updated all material to correspond to current state of XBRL 2.1 Recommendation and Conformance Suite. The Java and DotNet subdirectories were never needed and are only noted in passing. The dates on the schemas have changed. The file names of testcases and variations have now had numbers prepended to them and so the file names have been removed from the descriptions of the test goals.
2004-10-28	Van Ardenne	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
2004-11-11	Wallis	Editorial to incorporate comments from Atsushi Ohtake (of Hitachi) and to prepare for issue as a new Public Working Draft
2005-04-25	Wallis	Editorial to indicate status as a Candidate Recommendation.

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: Approval process (non-normative)

The approval process follows that described in xbrl-processes-REC-2002-04-02.

This section will be removed from the final Recommendation.

	Stage (* - Current)	Party responsible for decision	Next step	Revisions needed	Target date for stage completion
1	Internal WD	Spec WG	Recommend for Stage 2	Stay in Stage 1	2004-10-28
2	Internal WD pending publication.	ISC	Approve for Stage 3	Return to Stage 1	2004-11-11
3*	Public WD	WD Editor(s)	Minor revisions – to Stage 4	Major revisions, Restart Stage 1	2004-12-31
4	Last Call for Comments	Spec WG	Recommend for Stage 5	Restart Stage 3	2005-04-25
5	Candidate Recommendation	ISC	Approve for Stage 6	Restart Stage 4	2005-06-30
6	Recommendation	Done