FRTA 1.0 Conformance Suite

Recommendation of 2005-04-25

Corresponding to FRTA Recommendation dated 2005-04-25

This document:

FRTA-CONF-RECOMMENDATION-2005-04-25.htm

is a non-normative version of this document. The NORMATIVE version is in the file:

http://www.xbrl.org/technical/guidance/FRTA-CONF-RECOMMENDATION-2005-04-25.rtf

Source files:

http://www.xbrl.org/technical/guidance/FRTA-CONF-RECOMMENDATION-2005-04-25.zip

Unzip the latter into a {ROOT} directory to create a directory hierarchy. Open the file {ROOT}/index.xml in a browser. This yields a hypertext navigable tree view of test set lists, and a test list in each set of tests.

Editor

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

Contributors

Name	Contact	Affiliation
Satyen Choudhury	satyen.choudhury@ubmatrix.com	UBmatrix
Mark Goodhand	mrg@decisionsoft.com	Decisionsoft
Masatomo Goto	mg@jp.fujitsu.com	Fujitsu
Charles Hoffman	CharlesHoffman@olywa.net	UBmatrix
Walter Hamscher	walter@hamscher.com	Standard Advantage
Neil Wills	neil.wills@ubmatrix.com	UBmatrix

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. The XBRL Financial Reporting Taxonomies Architecture ([FRTA]) document describes the architecture of financial reporting taxonomies using the eXtensible Business Reporting Language [XBRL].

This document describes a set of conformance tests for processors that check conformance of XBRL taxonomies to [FRTA]. Unless indicated otherwise, references to ‘XBRL’ and ‘the specification’ in this document mean ‘XBRL 2.1’ and ‘the XBRL 2.1 specification recommendation’, respectively. Unless indicated otherwise, references to ‘FRTA’ in this document mean ‘FRTA 1.0’.

Status of this document

This is a Recommendation whose circulation is unrestricted The XBRL International Steering Committee approved this for publication on 2005-04-25. The XBRL International Steering Committee approved this for publication on 2005-04-25. Recipients of this document 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.

Editor i

Contributors. i

Abstract i

Status of this document i

Table of contents. iii

1.4 Documentation conventions 2

2 Changes from the previous recommendation. 2

3 Overview of the tests. 3

4 Technical details. 3

4.1 Directory Structure 3

4.2 Structure of Testcase Files 4

4.3 Contents of a variation 7

4.4 How to submit tests 8

A References (non-normative). 9

B Intellectual property status (non‑normative). 9

C Document history and acknowledgments (non-normative). 10

D Errata corrections incorporated in this document 10

List of Figures

Figure 1. Fragment of the root file index.xml 5

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

Figure 3. The file 202-00-ProperID-valid.xsd. 7

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

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

1.1 Purpose

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

The conformance suite is normative in the same sense that the specification [XBRL] is normative and [FRTA] is normative. An application is a FRTA Compliance Processor if and only if it passes all of the conformance suite tests. As noted in FRTA 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 FRTA 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 [FRTA] 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]

· 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 two main sets of tests for FRTA conformance are Schema and Linkbase 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}

· 200-Concepts – tests relating to the rules about concepts in [FRTA] chapter 2

· 300-Relationships – tests relating to the rules about relationships in [FRTA] chapter 3

· 400-DTS – tests relating to the rules about discoverable taxonomy sets in [FRTA] chapter 4

· 500-Extensions – tests relating to the rules about taxonomy extensions in [FRTA] chapter 5

· lib – the directory where the core XBRL and supporting schemas are found. While the date embedded in the file names is 2003‑12-31 it should be noted that these schemas reflect the most recent published schemas, which conform to the most recent errata corrected version of [XBRL]. At this time this is the version with errata corrections as of 2004-10-07. Note that there were no changes to the schemas between the 2004-04-29 set of errata corrections and the 2004-10-07 version.

Test cases themselves have their own subdirectory and are located within their parent subdirectories viz. 200-Concepts, 300-Relationships, 400-DTS, 500-Extensions. Subdirectory names are a concatenation of the test ID number and a human readable name. For example, all the files related to test case with ID “T-202”, which has a name “ElementID”, are in the subdirectory “202-ElementID”.

4.2 Structure of Testcase Files

The naming scheme of the test case files is in the form “TTT‑VV‑VariationName‑validity.extension.” Where:

· TTT is the numeric portion of the test case ID per the test case file. For example the test case “T-202” has the code “202”.

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

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

· validity indicates whether the test is expected to produce a result that is valid or invalid. A valid test (i.e. the taxonomy is valid according to [FRTA]) has the code “valid” and an invalid test (i.e. the taxonomy is invalid according to [FRTA]) has the code “invalid”.

· extension is “.xsd” or “.xml” depending on whether the file contains a taxonomy schema or a linkbase.

So, putting this all together, an example test case included in the “200-Concepts” directory, with the subdirectory “202-ElementID”, has the files:

· 202-00-ProperID-valid.xsd – the taxonomy schema

· 202-00-ProperID-valid-label.xml – the labels linkbase

· 202-00-ProperID-valid-presentation.xml – the presentation linkbase

The root file of the test suites is index.xml. This lists all the sets of tests in the suite. A portion of it is shown in the figure below.

Figure 1. Fragment of the root file index.xml

</testcases>

The testcases element has the following attributes:

· name - a brief name for the complete test suite

· date - date the test suite 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

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

id='T-202'

name='202-ElementId'

description='Concepts-FRTA 2.1.5-Element definitions for concepts in a persisting DTS MUST contain an *id* attribute whose value begins with the recommended namespace prefix of the taxonomy followed by an underscore.'

owner='mrg@decisionsoft.com'

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

minimal='true'

<description>ID attribute exists and is the namespace prefix, underscore, and element name concatinated together</description>

<data>

<xsd readMeFirst='true'>202-00-ProperID-valid.xsd</xsd>

<linkbase readMeFirst='false'>202-00-ProperID-valid-label.xml</linkbase>

<linkbase readMeFirst='false'>202-00-ProperID-valid-presentation.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 [FRTA] 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) 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, and linkbase 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.

· 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 FRTA 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 “202-00-ProperID-valid” variation in the testcase 202‑TestCase-ElementId. The goal of this specific variation is to ensure that the id attribute on each element in the taxonomy schema begins with the character string “frta-test”, which is the namespace prefix for the namespace to which the element belongs in the test schema.

The figures below show the taxonomy schema and the linkbases. The expected attribute of the result element is “valid”. The second variation in the test case has no id attribute on the elements and the third variation does have id attributes but they start with an invalid character string (“foo”), and the expected attribute of the result element is “invalid”.

Figure 3. The file 202-00-ProperID-valid.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'>

</appinfo>

</annotation>

</schema>

4.4 How to submit tests

If you are going to submit new or updated test cases or variations, you must have access to the CVS repository where the Conformance suite is stored. If you wish to submit tests please contact the editor or one of the authors of this document.

A References (non-normative)

[FRTA]	Walter Hamscher, Editor. Charles Hoffman, Josef MacDonald, Brad Homer, Geoff Shuetrim, Hugh Wallis Authors
	Financial Reporting Taxonomies Architecture 1.0.
	http://www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25.rtf

[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/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.rtf

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)

This conformance suite was written with the contribution of many people, particularly the participants of the XBRL Domain Working Group. The XBRL International Domain Group is chaired by Josef MacDonald of the IASCF, and its vice chair is Mark van Hilvoorde of PricewaterhouseCoopers.

Date	Editor	Remarks
2004-10-04	Hoffman	First draft of document prepared and distributed.
2004-11-05	Wallis	Updated to reflect public working draft status and modifications introduced to the suite since the initial draft of the document.
2005-02-04	Wallis	Updated to reflect candidate recommendation status.
2005-04-04	Wallis	Updated to reflect new date for candidate recommendation 2 and 2005 Domain Working Group Chair/Vice-Chair
2005-04-25	Wallis	Editorial to reflect Recommendation status

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 2005-04-25. 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 a candidate recommendation, there are no errata at this time.