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.

The Financial Reporting Taxonomies Architecture document [FRTA] documents the recommended architecture for taxonomies designed for the purpose of Financial Reporting. It establishes rules and conventions that assist in comprehension, usage and performance among different financial reporting taxonomies. “Financial reporting” encompasses disclosures derived from authoritative financial reporting standards and/or applicable generally accepted accounting practice/principles, regulatory reports whose subject matter is primarily financial position and performance including related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, reports that primarily consist of narrative (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements).

The Financial Reporting Instance Standards document FRTA aims to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers. The fundamental use case that guides the rules is the publication, by a single organization, of its financial reports, and the consumption of that financial report by many, initially unknown, users and software applications.

This document describes the conformance suite for Processors that claim to check instances for compliance with FRTA. Such processors are FRIS Compliance Processors.

1.1 Purpose

The purpose of the conformance suite is to facilitate consistency among FRIS Compliance Processors.

The conformance suite is normative in the same sense that the specification [XBRL] is normative and FRTA is normative. An application is an FRIS Compliance Processor if and only if it passes all of the conformance suite tests. As noted in FRIS Appendix C FRTA, some rules are not appropriate for fully automated checking. The conformance suite addresses only those rules which are appropriate, i.e. those indicated in the Table in section C of FRTA with the word “Auto” in the column with title “Approach”.

There are different levels of conformance:

Minimal Conformance: Processors correctly identify compliance or lack thereof with all mandatory rules in FRTA. i.e. those that are described using the word must (or must not). These rules are indicated in the table in Appendix C of FRTA by having the word “Yes” in the column with title MUST.

Full Conformance: In addition to satisfying the requirements for Minimal Conformance processors correctly identify all situations where a taxonomy fails to comply with FRTA rules described using the word should (or should not). These rules are indicated in the table in FRIS Appendix C FRTA by having the word “No” in the column with title must.

The conformance suite marks each test to indicate whether it is necessary for minimal or full Conformance.

1.2 Scope

Testing of applications that consume XBRL instances and the taxonomies used by those instances is included in the scope of this conformance suite.

Testing of applications that produce XBRL taxonomies is not within the scope of this conformance suite.

XBRL is in scope and FRIS 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].

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.

For definitions of the following terms see FRTA 1.0 [FRTA].

· DTS, base DTS, extension DTS, extended-type link, FRTA, GAAP, LRR, source, target, taxonomy status (acknowledged, approved, recommended), version control.

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:

HW: 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

There has been no previous recommendation, hence no changes.

3 Overview of the tests

The structure of the test suite is based on the OASIS XSL Conformance Suite and the XBRL 2.1 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 main set of tests for FRIS conformance is instance document 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}/index.xml file. In general each test may have zero or more of these different types of file:

· Instance: CamelCase style file name, suffix .xbrl;

· Schema: CamelCase style file name, suffix .xsd;

· Linkbase: CamelCase style file name, suffix .xml;

A numbering scheme organises the test sets and variations as detailed below in section 4.2, “Structure of Testcase Files”.

4 Technical details

4.1 Directory Structure

The conformance suite has a hierarchical tree structure. The structure segregates tests in to sections for usability and provides an individual subdirectory for each test case in which the test case summary file is provided and all files for all variations of each test case:

{ROOT}

· 500-Instance – tests relating to the overall instance document structure, schemaRef, linkbaseRef

· 600-Contexts – tests relating to contexts, entities, segments, scenarios, etc

· 700-Units – tests relating to units

· 800-Facts – tests relating to items and tuples

· 900-Footnotes – tests relating to footnote links

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

· Taxonomies – the directory where taxonomies used by the instance documents are located; all taxonomies are comply with FRTA

Test cases themselves have their own subdirectory and are located within their parent subdirectories 500-Instance, 600-Contexts, 700-Units, 800-Facts, 900-Footnotes. Subdirectory names are the test ID number to help organize the test case and a human readable name. For example, test case ID “T-602” which has a name “EqualContexts” has a subdirectory name of “602-EqualContexts”.

4.2 Structure of Testcase Files

The naming scheme of the test case files is in the form:

TTT-VV-VariationName-validity.xbrl

Where

· TTT is the numeric portion of the test case ID per the test case file. For example the test case “T-602”, the code would be “602”.

· VV is the numeric portion of the test case variation number per the test case file. For example the variation, “V-01”, the code would be “01”.

· VariationName is the name of the variation per the test case file. For example, the variation name “NoEqualContexts”.

· validity is whether the test is valid or invalid. For example, a valid test would be “valid” and an invalid test would be “invalid”.

· The extension for all files is “.xbrl” which is recommended by FRIS.

So, putting this all together, an example test case file name which would be included in the “600-Contexts” directory, with the subdirectory “602-EqualContexts”, would have the file:

· 602-01-EqualContexts-invalid.xbrl

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

Figure 1. Fragment of the root file index.xml

<?xml version='1.0' encoding='UTF-8'?>

<?xml-stylesheet type='text/xsl' href='testcases.xsl'?>

... other elements removed...

</testcases>

The testcases element has the following attributes:

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

· owner: email address 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 {ROOT}/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 2. A testcase consists of one or more variations

<?xml version='1.0'?>

<?xml-stylesheet type='text/xsl' href='../../testcase.xsl'?>

<testcase xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'

id='T-502'

name='502-EqualContexts'

description='Contexts-FRTA 2.4.1-An instance MUST NOT contain s-equal contexts.'

owner='neil.wills@ubmatrix.com'

xsi:noNamespaceSchemaLocation='../lib/test.xsd'

minimal='true'

<description>There are no equal contexts in the instance</description>

<data>

<instance readMeFirst='true'>502-00-NoEqualContexts-valid.xbrl</instance>

<xsd readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy.xsd</xsd>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-label.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-presentation.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-calculation.xml</linkbase>

</data>

</variation>

<description>There are equal contexts in the instance</description>

<data>

<instance readMeFirst='true'>502-01-EqualContexts-invalid.xbrl</instance>

<xsd readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy.xsd</xsd>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-label.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-presentation.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-calculation.xml</linkbase>

</data>

</variation>

</testcase>

The testcase element has the following attributes

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

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

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

· minimal: (optional, default value true) 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:

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

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

· 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).

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.

4.3 Contents of a variation

An example of a variation is the “602-00-EqualContexts” variation in the testcase 602‑EqualContexts. The goal of this specific variation is to ensure that there are no equal contexts in the instance. The way to do this is to ensure that the processor will detect that it is invalid only if it actually has two s-equal contexts. Figure 3 below shows the variation declaration itself. Notice that the relative pathnames of one of the input files places it into a subdirectory of where the DTS file is located.

Figure 3. Variation “602-00-EqualContexts” in testcase “602-EqualContexts”

<?xml version='1.0'?>

<?xml-stylesheet type='text/xsl' href='../../testcase.xsl'?>

<testcase xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'

id='T-602'

name='602-EqualContexts'

description='Contexts-FRTA 2.4.1-An instance MUST NOT contain s-equal contexts.'

owner='neil.wills@ubmatrix.com'

xsi:noNamespaceSchemaLocation='../lib/test.xsd'

minimal='true'>

<description>There are no equal contexts in the instance</description>

<data>

<instance readMeFirst='true'>602-00-NoEqualContexts-valid.xbrl</instance>

<xsd readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy.xsd</xsd>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-label.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-presentation.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-calculation.xml</linkbase>

</data>

</variation>

<description>There are equal contexts in the instance</description>

<data>

<instance readMeFirst='true'>602-01-EqualContexts-invalid.xbrl</instance>

<xsd readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy.xsd</xsd>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-label.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-presentation.xml</linkbase>

<linkbase readMeFirst='false'>../../Taxonomies/frta-valid-taxonomy-calculation.xml</linkbase>

</data>

</variation>

</testcase>

The figures below show the instance and taxonomy files. Notice that the instance file does not have duplicate contexts, so the document will be valid. Hence, the expected attribute of the result element is “valid”. The second variation in the test case has an instance document which has duplicate contexts, and the expected attribute of the result element is “invalid”.

Figure 4. File “602-00-NoEqualContexts-valid.xbrl”

<?xml version='1.0' encoding='utf-8'?>

<xbrl xmlns='http://www.xbrl.org/2003/instance'

xmlns:xlink='http://www.w3.org/1999/xlink'

xmlns:link='http://www.xbrl.org/2003/linkbase'

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

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

xmlns:frta-test='http://www.xbrl.org/FRTA/Compliance'

xsi:schemaLocation='http://www.xbrl.org/FRTA/Compliance ../../Taxonomies/frta-valid-taxonomy.xsd'>

</entity>

</period>

</context>

</entity>

</period>

</context>

</unit>

<frta-test:Land id='Item-01' contextRef='I-2003' unitRef='U-Monetary' decimals='INF'>5347000</frta-test:Land>

<frta-test:Land id='Item-02' contextRef='I-2002' unitRef='U-Monetary' decimals='INF'>1147000</frta-test:Land>

<frta-test:Building id='Item-03' contextRef='I-2003' unitRef='U-Monetary' decimals='INF'>244508000</frta-test:Building>

<frta-test:Building id='Item-04' contextRef='I-2002' unitRef='U-Monetary' decimals='INF'>366375000</frta-test:Building>

</xbrl>

Figure 5. Schema “frta-valid-taxonomy.xsd”

<?xml version="1.0" encoding="utf-8"?>

<schema

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

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

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

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:frta-test="http://www.xbrl.org/FRTA/Compliance"

targetNamespace="http://www.xbrl.org/FRTA/Compliance"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

</link:roleType>

</appinfo>

</annotation>

</sequence>

</restriction>

</complexContent>

</complexType>

</element>

</schema>

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

4.4 How to submit tests

To submit new or updated test cases or variations, contact the editors, who have access to the CVS repository where the Conformance suite is maintained.

A References (non-normative)

[FRIS]	Mark Goodhand, Walter Hamscher, Editors. Charles Hoffman, Josef Macdonald, Authors
	Financial Reporting Instance Standards 1.0.
	http://www.xbrl.org/TechnicalGuidance/

[FRTA]	Walter Hamscher, Editor. Charles Hoffman, Josef MacDonald, Jeffrey Naumann, Geoff Shuetrim, Authors
	Financial Reporting Taxonomies Architecture 1.0.
	http://www.xbrl.org/TechnicalGuidance/

[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, with corrected errata dated 2004-04-29
	http://www.xbrl.org/Specifications/

B 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).

C Document history and acknowledgments (non-normative)

The conformance suite was written with the contribution of many people, particularly the participants of the XBRL Domain Working Group. The XBRL International Domain Working Group is chaired by John Turner, KPMG, and its vice chair is Josef MacDonald of the IASCF.

Date	Editor	Remarks
2004-11-05	Hoffman	First draft of document prepared and distributed.
2004-11-05	Hamscher	Formatting and typographical corrections.
2004-11-14	Hamscher	Preparation of public working draft.

D Errata corrections incorporated in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Domain Working Group (DWG) up to and including 2004-11-14. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

Erratum number	Brief description and link(s) to relevant discussion thread(s)	Affected section(s)	Date Correction Approved by the DWG

Because this is an internal working draft, there are no errata at this time.

Name	Contact	Affiliation
Hugh Wallis	hugh@standarddimensions.com	Standard Dimensions

Name	Contact	Affiliation
Walter Hamscher	walter@hamscher.com	Standard Advantage
Charles Hoffman	CharlesHoffman@olywa.net	UBmatrix

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

Editor

Contributors

Abstract

Status of this document

Table of contents

List of Figures

1 Introduction

1.1 Purpose

1.2 Scope

1.3 Terminology

1.4 Documentation conventions

2 Changes from the previous recommendation

3 Overview of the tests

4 Technical details

4.1 Directory Structure

4.2 Structure of Testcase Files

4.3 Contents of a variation

4.4 How to submit tests

A References (non-normative)

B Intellectual property status (non‑normative)

C Document history and acknowledgments (non-normative)

D Errata corrections incorporated in this document

E Approval process (non-normative)