XBRL Versioning 1.0 Conformance Suite

Public Working Draft of 2007-11-28

Corresponding to XBRL Versioning Specification Public Working Draft dated 2007-11-28

This document:

XVS-CONF-PWD-2007-11-28.htm

is NON-NORMATIVE. The NORMATIVE version is in the file XVS-CONF-PWD-2007-11-28.rtf

Source files:

XVS-CONF-PWD-2007-11-28.zip

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

Authors

Name	Contact	Affiliation
Ignacio Hernández-Ros	ignacio@reportingstandard.com	Reporting Estandar S.L.
Katrin Schmehl	Katrin.Schmehl@bundesbank.de	Deutsche Bundesbank

Contributors

Name	Contact	Affiliation

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 Versioning 1.0 specification document defines the syntax and semantics of the versioning report. The versioning report represents the changes made to the concept definitions and resource definitions that exist in two different DTSs. The information that is communicated in the versioning report has two purposes. Firstly there is the set of changes that software can identify comparing the concept definitions that appear in the two DTSs. Secondly, the versioning report is a communication tool that satisfies higher level business requirements about what changes are made. This includes human readable documentation about the changes and the creation of groups of change events to indicate concept splits and concepts combined together.

This document describes a set of conformance tests for XBRL processors that create versioning reports on basis of two versions of XBRL taxonomies and check conformance of XBRL versioning reports against the XBRL Versioning specification 1.0.

Status of this document

Circulation of this Public Working Draft is unrestricted. Recipients of this draft are invited to submit comments to the authors and contributors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of contents

1.4 Documentation conventions 2

2 Overview of the tests 3

3 Technical details 4

3.1 Directory Structure 4

3.2 Structure of Test case files 4

3.3 How to submit tests 7

3.4 How to check conformance of a versioning processor 7

A References (non-normative) 9

B Intellectual property status (non‑normative) 9

C Document history and acknowledgments (non-normative) 10

List of Figures

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

Figure 2. A testcase example. 6

Introduction

The XBRL Versioning Specification defines the syntax and semantics of the versioning report. The versioning report represents the changes made to the concept definitions and resource definitions that exist in two different DTSs in a standardised way. These two DTSs can be two consecutive versions of the same DTS or two different extensions of a base taxonomy. The versioning report should contain the set of differences between the compared DTSs and also include information about the business or technical reasons that lead to these changes. The versioning report is meant as communication tool that enable taxonomy authors to communicate differences between DTSs; but the content of the versioning report is not just the set of differences between two DTSs. Taxonomy authors have the right to ignore some of the differences or group the changes in a more convenient way.

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

1.1 Purpose

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

The conformance suite is normative in the same sense that the specification [XBRL] is normative and [XVS] is normative. An application is a XVS Compliance Processor if and only if it passes all of the conformance suite tests. In this case, the processor is declared as XVS 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 not 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 applications that produce XBRL instance documents is in the scope of this conformance suite.

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

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 Overview of the tests

The structure of the test suite is similar to the XDT Conformance Suite to some extend. In the case of XVS conformance suite the structure of each individual test is simple:

· A launch .xml file;

· A .xsl style sheet;

· The set of assignments and actions and grouping of events and event differences expected to be produced by tools comparing the two DTSs is also integrated in the launch .xml file. In this sense, the launch file is like a versioning report in raw xml.

Each test case of the XVS conformance suite consists of one .xml launch file. The launch file refers to the two DTSs that must be compared. The launch file contains also predefined mapping rules that would be defined by a taxonomy author before the generation of the versioning report in an XBRL software. A possible result of the comparison is covered in xml structures for actions, events and assignments that are objects of the versioning report.

The three main sets of tests for XVS conformance are:

1. Test cases concerning changes on concept level

2. Test cases concerning changes on relationships

3. Test cases concerning changes on resources

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}/xvt.xml file. In general each test may have one or more of these different types of file:

· Schema: “dts” + use-case number + alphabetical numbering file name, suffix .xsd;

· Linkbase: “dts” + use-case number + alphabetical numbering file name, suffix .xml;

A numbering scheme organises the test sets and variations as detailed below in section 3.2, “Structure of Test case files”.

3 Technical details

3.1 Directory Structure

The conformance suite provides test cases for use-cases defined in the document “Versioning Specification Requirements”. The hierarchical tree structure is based on folders that refer via use-case number to a defined requirement. These folders contain one or more launch files and the taxonomies that are referenced in the launch files. Variations of the test cases are marked with an additional alphabetical letter in the launch file names:

· dts1217a-dts1217b – test case that compares the taxonomy dts1217a.xsd with the
taxonomy dts1217b.xsd.

· lib – the directory where common schemas reside. There are two schema files, one for the structure of the launch files and another for the versioning taxonomy.

3.2 Structure of Test case files

The naming scheme of the test case summary files is in the form “dtsUsecaseFromLetter- dtsUsecaseToLetter.extension”

Where:

· dts is the fixed string prefix for the DTS that should be compared. The test case ID per the test case file.

· UseCase is the numeric portion of the use-case. For example “1217” is the number for the requirement “Addition of a new resource… MUST be documented”.

· FromLetter and ToLetter is an ascending alphabetical letter for the taxonomy files.

· extension is “.xml”.

So, putting this all together, an example test case included in the “case1217-new-resource” directory, has the files “dts1217a-dts1217b.xml”, “dts1217c-dts1217d.xml” etc. that contain the different variations of the use-case: “New resource(s) in the following version of the taxonomy”.

The root file of the test suites is xvt.xml. This lists all the launch files in the suite. A portion of it is shown in the figure below.

Figure 1. Fragment of the root file xvt.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. This is the URI of the launch file.

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

The launch file that contains the test case is an XML document but not an XBRL instance document.

The structure of a testcase file is described by the schemas {ROOT}/lib/versioning-conf-suite-2007-11-02.xsd and {ROOT}/lib/versioning-2007-11-02.xsd. The figure below shows one testcase. 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 example

</version>

<text>This is the text that will appear in the generic linkbase label</text>

</assignment>

<ver:event>

<ver:EvConceptRelationshipFrom>

<ver:fromConceptId ver:concept="f0:ConceptA" />

<ver:toConceptId ver:concept="f0:ConceptA" />

<ver:EvNewRelationship>

           <ver:toRelationshipId ver:extendedLinkRole="http://www.xbrl.org/2003/role/link"
                                 ver:relationshipType="link:labelArc"
                 ver:arcrole="http://www.xbrl.org/2003/arcrole/concept-label">

<ver:conceptAsSourceId ver:concept="f0:ConceptA" />

<ver:resourceAsTargetId ver:resourceRef="linkbase.xml#label8"/>

</ver:toRelationshipId>

</ver:EvNewRelationship>

</ver:EvConceptRelationshipFrom>

<ver:EvResourceNew>

<ver:toResourceId ver:resourceRef="linkbase.xml#label8"/>

</ver:EvResourceNew>

</ver:event>

<text>This is documenting the addition of a new resource and the usage of the
resource as label to ConcentA</text>

</action>

</testcase>

The testcase element has the following attributes

· owner: the name of the owner of the test case.

· email: the e-mail address of the main contact for the test case.

· usecase: the number of the use-case in the requirements document and a short description of the use-case.

The testcase contains a vReport and a description element. The vReport element has the following parts:

· version (element): an element to encapsulate URLs to the taxonomy files to be compared and the mapping rules as pre-conditions for the generation of the versioning report. The version element may contain mapping tables for concepts (conceptMap), roles (roleMap), namespaces (namespaceMap) and resources (resourceMap). The xml structure of this element is similar to the structure of the version element in the versioning report [XVS 3.10] but in the launch file it does not contains contextRef attributes.

· assignment (element): this element contains:

o Optionally, the change categories the assignment belongs to. Possible change categories are “business”, “technical” and “errata”.

o Optionally, reference to actions.

o Optionally, human readable documentation about the assignment.

The syntax of this element differs from the syntax on an assignment element in the versioning report [XVS 3.4] although it contains the same information.

· action (element): an element to encapsulate the diff events that are generated by XVS processors comparing the From and To DTSs. The action element contains an id attribute. The structure of the diff events is the same defined in the versioning taxonomy referenced in the XVS specification. Diff events in the launch file are equivalent to diff events in the real versioning report [XVS 3.5].

result (element): an URI pointing to a file that contains a single event element as a container of all diff events between the From DTS and the To DTS.

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

3.3 How to submit tests

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

3.4 How to check conformance of a versioning processor

A processor that claims to be an XBRL 2.1 versioning processor MUST demonstrate it is conformant to this conformance suite.

In order to do so, a versioning processor MUST be able to access to the xvt.xml file and iterate through all test cases defined performing the following operations:

1. Open the file pointed to by the uri attribute on the testcase element.

2. Obtain information about the From DTS and the To DTS by looking at the content
of the version element and in particular to the fromURL and toURL elements.

Obtain information about the following four mapping tables:

The namespace mapping table,
The role URI mapping table,
The concept mapping table, and
The resource mapping table.

The processor MUST be able to resolve the correspondent information item to
another information item according to section 2.4 of the [XVS] specification. The
process requires to access to information that exists in these tables in order to
produce the expected result.

Compare the From DTS with the To DTS and generate the set of diff events.

5. Compare the set of generated events with the content of the file indicated in the result element of the test case. This step can be implemented in two different ways:

a. By generating another file with the same content as the out file. The content of the generated file and the existing file MUST be equivalent. Equivalency of the content of the two files is not syntactical. The following constraints MUST be observed:

i. Both XML files MUST have the same number of diff events. A diff event is one child of the event node which is the root node of the file.

ii. For each diff event in the file pointed to by the result element in the test case; another equivalent diff event MUST exist on the file generated by the processor.

iii. Two diff events are equivalent if they are of the same type and points to the same information items in the From DTS and in the To DTS respectively. The values of the generated XPointers according to the [XVS] specification may be different in its syntax but they MUST point to the same information item in the corresponding DTS.

b. By loading the file pointed to by the result element in the test case in memory and comparing the events in order to make sure constraints (i,ii and iii) above are observed.

A References (non-normative)

[XVS]	Ignacio Hernández-Ros
	XBRL Versioning Specification 1.0


[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 2006-12-18
	http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2006-12-18.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)

Date	Editor	Remarks
2007-10-31	KS	First draft of document prepared.
2007-11-02	KS	Addition of references to the XVS document
2007-11-02	IHR	Editorial changes and example launch file updated according to the latest XVS taxonomy (2007-11-02)
2007-11-18	IHR	Added the result element in section 3.2 Added new chapter 3.4
2007-11-28	HW	Editorial for publication as a Public Working Draft