Corresponding to Dimensions 1.0 Recommendation dated 2006-09-18 with errata corrections to 2009-09-07

This document:

XDT-CONF-CR4-2009-10-06.htm

is the NON-NORMATIVE version of this document. The NORMATIVE version is in the document XDT-CONF-CR4-2009-10-06.rtf

Source files:

XDT-CONF-CR4-2009-10-06.zip

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

A Editor

Name	Contact	Affiliation
Hugh Wallis	hughwallis@xbrl.org	XBRL International Inc.

B Contributors

Name	Contact	Affiliation
Herm Fischer	herman.fischer@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 Dimensions 1.0 specification document describes the elements and data structures that can be constructed using XBRL Taxonomies to standardize the content of the segment and scenario containers within the context of facts that exist in XBRL instance documents.

This document describes a set of conformance tests for dimensional processors that check conformance of XBRL instance documents and taxonomies against the XBRL Dimensions specification 1.0. 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 ‘XDT’ in this document mean ‘XBRL Dimensions 1.0’.

Status of this document

This is a Candidate Recommendation whose circulation is unrestricted. 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.

XBRL Dimensions 1.0 Conformance Suite. i

Candidate Recommendation of 2009-10-06 i

Corresponding to Dimensions 1.0 Recommendation dated 2006-09-18 with errata corrections to 2009-09-07 i

A Editor i

B Contributors. i

Abstract i

Status of this document i

Table of contents. ii

1.4 Documentation conventions 2

2 Changes from the previous recommendation. 2

3 Overview of the tests. 2

4 Technical details. 3

4.1 Directory Structure 3

4.2 Structure of Testcase summary files 3

4.3 Contents of a variation 6

4.4 How to submit tests 7

C References (non-normative). 8

D Intellectual property status (non‑normative). 8

E Document history and acknowledgments (non-normative). 9

List of Figures

Figure 1. Fragment of the root file xdt.xml 4

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

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 XBRL Dimensions 1.0 specification documents the architecture and syntax of elements that provide multiple dimensions to facts that exist in instance documents using the segment and scenario container in the context of such facts. The XBRL Dimensions 1.0 specification also defines validation rules that can be used to define and check the expected dimensions for each fact and dimension value combinations that are valid or invalid.

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

1.1 Purpose

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

The conformance suite is normative in the same sense that the specification [XBRL] is normative and [XDT] is normative. An application is a XDT Compliance Processor if and only if it passes all of the conformance suite tests. In this case, the processor is declared as XDT Conformant.

This conformance suite does not mark each test to indicate whether it is necessary for minimal or full Conformance. All test cases are considered minimal.

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.

Testing of APIs that produce XBRL instance documents is not within the scope of this conformance suite.

[XBRL] is in scope and [XDT] 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 [XDT]

· Dimension, Domain, Effective Domain, Domain Member / Valid Member, Explicit Dimension, Typed Dimension, Empty Dimension, Primary Item, Primary Item Declaration, Primary Item Descendant, Primary Taxonomy, Dimensional Taxonomy, Template Taxonomy, Hypercube, Empty Hypercube, Hypercube Declaration, Dimension Declaration, Typed Dimension Element, Dimensional relationship set, Base Set, Dimensional Processor, Raise an error.

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:

IHR: This highlighting is used to indicate editorial comments about the current document, 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 three main sets of tests for XDT conformance are:

1. Schema Invalid test cases,

2. Dimensional taxonomy errors tests and

3. Instance document error 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}/xdt.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 summary files”.

4 Technical details

4.1 Directory Structure

The conformance suite has a hierarchical tree structure. The structure segregates tests into sections for usability and provides an individual subdirectory for each section. Inside the sections there are additional subdirectories, one per expected error message. Each subdirectory contains the test case summary file and all files for all variations of each test case:

{ROOT}

· 000-Schema-invalid – tests that should raise schema validation errors.

· 100-xbrldte – tests relating to taxonomy errors.

· 200-xbrldie – tests relating to instance document errors.

· lib – the directory where common schemas reside. There is only one common schema in that folder that is the test.xsd schema.

· lib/base – the directory where common taxonomies used in multiple test cases reside. The taxonomies found in this folder are valid XBRL 2.1 taxonomies and schemas.

Test cases themselves have their own files and are located within their parent subdirectories viz. 203-PrimaryItemDimensionallyInvalidError, 105-HasHypercubeTargetError, etc. each one of the folders contains a test cases file.

4.2 Structure of Testcase summary files

The naming scheme of the test case summary files is in the form “TTT‑TestCase-ErrorName.extension.” Where:

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

· TextCase is the fixed string “TextCase”.

· ErrorName is the error condition that some of the test cases must raise.

· extension is “.xml”.

So, putting this all together, an example test case included in the “200-xbrldie” directory, with the subdirectory “204-RepeatedDimensionInInstanceError”, has one file “204-TestCase-RepeatedDimensionInInstanceError.xml” that describes the different variations.

The root file of the test suites is xdt.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 xdt.xml

<testcase uri="100-xbrldte/105-HasHypercubeTargetError/105-TestCase-HasHypercubeTargetError.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.

The schema xdt.xsd defines the structure of the file xdt.xml.

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

<description reference="XDT-IWD-2005-12-10.doc#3.1.3.2">1. A context MUST NOT contain more than one dimension value for every dimension. A validator MUST signal [Ins Err, 7] xbrldie:RepeatedDimensionInInstance when this rule is violated. In this valid variation only one dimension value is provided.</description>

<data>

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

<linkbase readMeFirst="false">contextContainsRepeatedDimension-definition.xml</linkbase>

<linkbase readMeFirst="false">contextContainsRepeatedDimension-label.xml</linkbase>

<instance readMeFirst="true">contextContainsTypedDimensionValid.xbrl</instance>

</data>

</result>

</variation>

<description reference="XDT-IWD-2005-12-10.doc#3.1.3.2">1. A context MUST NOT contain more than one dimension value for every dimension. A validator MUST signal [Ins Err, 7] xbrldie:RepeatedDimensionInInstance when this rule is violated. In this case two customer names are provided for the same context segment.</description>

<data>

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

<linkbase readMeFirst="false">contextContainsRepeatedDimension-definition.xml</linkbase>

<linkbase readMeFirst="false">contextContainsRepeatedDimension-label.xml</linkbase>

<instance readMeFirst="true">contextContainsRepeatedDimension.xbrl</instance>

</data>

<error>xbrldie:RepeatedDimensionInInstanceError</error>

</result>

</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 [XDT] 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.

· outpath: (unused) normally set to the string "out"

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.

· reference (attribute to the description element): a text string of the form filename#a.b.c.d where filename is the XDT file name and section is the dot separated section number.

· data (element): an element to encapsulate the files that are part of the variation.

· xsd, linkbase and instance elements: these elements give the relative pathname of the input files to the XBRL dimensional 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 element: this element declare the expected result of the variation. If the content of the result element is the empty sequence the result is valid.

· Possible error elements are: error, warning and inconsistency. The content of those elements is always one of the QNames defined in the XDT specification.

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 “204-RepeatedDimensionInInstanceError” variation in the testcase 200‑xbrldi. The goal of this specific variation is to ensure that there is no more then one value reported for a dimension.

The figures below show the instance document that is invalid. There is another variation of the same test case that is valid. The content of the result element is “<error>xbrldie:RepeatedDimensionInInstanceError</error>” in the invalid test case and nothing in the valid test case.

Figure 3. The file contextContainsRepeatedDimension.xbrl

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

xmlns:pr="http://www.xbrl.org/dim/conf/primary"

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

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

xmlns:tx="http://www.xbrl.org/dim/conf/389/contextContainsRepeatedDimension"

xmlns:cc="http://www.example.com/customer-code"

xmlns:xbrldi="http://xbrl.org/2006/xbrldi"

xsi:schemaLocation="http://www.xbrl.org/dim/conf/389/contextContainsRepeatedDimension contextContainsRepeatedDimension.xsd http://xbrl.org/2006/xbrldi http://www.xbrl.org/2006/xbrldi-2006.xsd http://www.xbrl.org/2003/instance http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd http://www.xbrl.org/dim/conf/primary ../../lib/base/primary.xsd http://www.example.com/customer-code ../../lib/base/cust-code.xsd">

<link:schemaRef

xlink:type="simple"

xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"

xlink:href="contextContainsRepeatedDimension.xsd"/>

<identifier scheme="http://www.example-dims.com"

>Example Dimensional Company</identifier>

<xbrldi:typedMember dimension="tx:hc_CustCodeDim">

<cc:customer>a123</cc:customer>

</xbrldi:typedMember>

<xbrldi:typedMember dimension="tx:hc_CustCodeDim">

<cc:customer>b123</cc:customer>

</xbrldi:typedMember>

</segment>

</entity>

</period>

</context>

</unit>

<pr:Sales decimals="2" contextRef="ctx1" unitRef="Euros">1000000.00</pr:Sales>

<pr:CostOfSales decimals="3" contextRef="ctx1" unitRef="Euros">750000</pr:CostOfSales>

<pr:GrossProfit decimals="0" contextRef="ctx1" unitRef="Euros">250000</pr:GrossProfit>

<pr:RevenueTotal decimals="0" contextRef="ctx1" unitRef="Euros">1000000</pr:RevenueTotal>

</xbrl>

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.

C References (non-normative)

[XDT]	Ignacio Hernández-Ros, Hugh Wallis
	XBRL Dimensions 1.0 CR3.
	http://www.xbrl.org/Specification/XDT-CR3-2006-04-26.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

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

E Document history and acknowledgments (non-normative)

This conformance suite was written with the contribution of many people, particularly the participants of the XBRL Specification and Domain Working Groups.

Date	Editor	Remarks
2006-06-10	IHR	First draft of document prepared and distributed according to XDT Dimensions CR3.
2009-10-06	HW	Updated to reflect Dimensions 1.0 Recommendation dated 2006-09-18 with errata corrections to 2009-09-07