Versioning Conformance Suite 1.0

Public Working Draft 19 October 2011

Copyright ©2011 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/WGN/versioning-conformance/PWD-2011-10-19/versioning-conformance-WGN-PWD-2011-10-19.html>
Editor:
Roland Hommes, Rhocon <roland@rhocon.nl>
Contributors:
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.com>
Herm Fischer, Mark V Systems <fischer@markv.com>

Status

Circulation of this Public Working Draft is unrestricted. Other documents may supersede this document. Recipients are invited to submit comments to versioning-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document is a Working Group Note, based on the Versioning Conformance Suite for versioning specifications. It provides important information to understand file structure and contents of the Conformance Suite and their usage.

Table of Contents

1 Introduction
2 Structure
2.1 Versioning report creation testing structure
2.2 Versioning report consumption testing structure
2.3 Relative file references and schemaLocations
3 Testing versioning report creation
4 Testing versioning report consumption
5 Normative schemas
5.1 Testcases Index File
5.2 Testcase Variations File
6 Intellectual property status (non-normative)
7 Acknowledgements (non-normative)

Appendices

A Document history (non-normative)
B Errata corrections in this document


1 Introduction

This document provides an overview of the content provided through the Versioning conformance suite. The Versioning conformance suite is designed to test two uses of the specification: creating a versioning report and consuming a report. All test cases are modular in line with the modular structure of the suite of Versioning specifications itself. The file and folder conventions described in this document are valid for all versioning modules covered by this conformance suite.

2 Structure

To provide a testing engine all the necessary input and output files, a special instance describing the locations and names of these files has been created. This schema is placed in the /conf folder. There are two of these index files, one for creation and one for consumption of versioning reports.

The structure of these 'master' index files provides an @uri which points to an index file per folder of test cases. The detail index file for creation test cases is aware of multiple variations and the predicted output files.

The detail index file for consumption test cases represents the error codes that the versioning module has defined and relies on the versioning report itself. The from and to DTS leading up to this report are also supplied.

2.1 Versioning report creation testing structure

The local detail index file is referred to by the master index file. Each folder with creation test cases represents an XBRL aspect that is being covered with the versioning specification (e.g. element, @balance, @weight etc.) and can have a number of variations that need testing.

The XML schema that validates the local index file is located in the /conf/infrastructure folder and supports specific elements that lead to the output requirements.

XPath Use
testcase/creator/name The name of the person who created the test cases
testcase/creator/email The email address of the creator
testcase/number The unique number for the (series of) test cases
testcase/name A short name for the test case
testcase/description An explanation of what the test is about
testcase/reference/@specification The name of the versioning module(s) this test is addressing
testcase/reference/@id Points to the use case number
testcase/variation/@id The unique identification for the variation
testcase/variation/description An explanation of what the variation is about
testcase/variation/data/schema The filename of the schema(s) involved
testcase/variation/data/schema/@dts Whether the schema is the from or to DTS
testcase/variation/data/parameter/@name Type of business user input; see note
testcase/variation/data/parameter/@value Type of business user input; see note
testcase/variation/result/versioningReport The folder/filename of the expected result

Note: The testcase/variation/data/parameter/@name node can contain the values:

  • "ExpectedAssignment": which indicates business user input to steer the category of ver:assignment content for any change found. Be aware that some of the events CAN have multiple reasons for changing.
  • "ExpectedEvent"" which indicates business user input to steer the expected event. This input MUST NOT be used to generate the versioning report. ONLY when differences have been found between the produced and expected result can this parameter clarify the differences found, which MAY lead to changing the versioning report event(s).

2.2 Versioning report consumption testing structure

The testing of the consumption is limited to loading and validating versioning reports.

Each versioning module has its own folder that has sub folders for each defined error message. Inside each folder there is an index file containing pointers to the from and to DTS and the versioning report. For test case variations where the report is invalid, expected errors are noted in the testcase variation <result> element. An expected error is specified by an <conf:error> element. There can be more than one error, although the test cases will make sure that all errors are of the same type. Testcase variations of reports that are not invalid will have no <conf:error> elements. How and when the error is being brought to the user is up to the software creator.

XPath Use
testcase/creator/name The name of the person who created the test cases
testcase/creator/email The email address of the creator
testcase/number The unique number for the (series of) test cases
testcase/name A short name for the test case
testcase/description An explanation of what the test is about
testcase/reference/@specification The name of the versioning module(s) this test is addressing
testcase/reference/@id Points to the use case number
testcase/variation/@id The unique identification for the variation
testcase/variation/description An explanation of what the variation is about
testcase/variation/data/versioningReport The folder/filename of the input versioning report
testcase/variation/data/schema The filename of the schema(s) involved
testcase/variation/data/schema/@dts Whether the schema is the from or to DTS
testcase/variation/result/error An error that is expected to be detected in validating the input versioning report

2.3 Relative file references and schemaLocations

The index files, testcase variation files, testcase schema files and report files must all use relative URIs and relative hrefs to refer between themselves and to any versioning schema files. All files that contain namespace prefix declarations for versioning schema files (by xmlns) will contain relative schemaLocations to the versioning schema files. This assures that testcase archive files, SVN-located files, and local copies of the testcases are self-referential and do not refer to 'official' xbrl.org web-hosted schema files (that may be of a version different that that for which the testcases are intended).

3 Testing versioning report creation

The testing engine must compare the produced results with the results provided in the conformance suite. However, there are some exceptions in which variation from the provided results are permitted as follows:

  1. The ver:assignment/@id and ver:action/@id carry random values; the ver:assignmentRef/@ref needs to link the appropriate @id on the ver:assignment.
  2. The content of the ver:assignment cannot always be deduced from a technical perspective and sometimes needs business user input to declare that a certain event has been entered for business reasons, leading to the inclusion of a ver:businessCategory assignment. The detail index file indicates this user input (see Section 2.1).
  3. There are no generic labels with useful comments attached to each assignment and action, the specification permits this.
  4. The grouping of certain events into a single action is allowed by the specification. On the other hand for the merging and splitting of concepts the action represents a different layer of business information. Test cases have never been merged where that would have been allowed. Only in the case of splitting and merging the conceptAdd and conceptDelete have events been grouped into a single action.
  5. Some actions address both a business and technical assignment. There are two means of making this reference: a single action contains two ver:assignmentRef nodes or the ver:assignment contains two categories. Both are valid options. Test cases use only the latter one.
  6. No specific order between assignments and actions is assumed.
  7. On verrels:relationships it is optional to include the attribute on the arc that has been changed (e.g., @preferredLabel, @weight etc.). Software could also deduce this change. Test cases have opted to include these attributes (and their values) where allowed.
  8. On verrels:relationships it is optional to list the link and arc element indicating 'all' relationships that are found using the explicit linkrole and arcrole. Test cases are always explicit.

For all test cases that can directly be linked to user requirements, this is done inside the detail index files.

4 Testing versioning report consumption

The testing engine must load the versioning report specified as input, and its DTSes, sufficiently to perform report validation. Validation will at least identify errors that are listed in the versioning specifications. The testing engine for consumption will validate testcase variation input versioning reports and identify errors. It will match observed validation errors with the expected error codes of the test case variation. For test case variations that have no expected error codes, the engine will conversely assure that the versioning report validator does not detect any unexpected errors.

There is no rendering prescribed by the specification or implied by consumption testing. There is no mandatory process defined specifying how a versioning report should affect an instance or mapping table. There is no validation that an application consuming a versioning report can produce an instance of the toDTS from one of the fromDTS, or update a report-consuming application's mapping table correctly.

5 Normative schemas

5.1 Testcases Index File

<xs:schema
xmlns:xs
="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="testcase">
<xs:complexType>
<xs:attribute name="uri" use="required" type="xs:anyURI"/>
</xs:complexType>
</xs:element>
<xs:element name="testcases">
<xs:complexType>
<xs:sequence>
<xs:element ref="testcase" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" use="required" type="xs:string"/>
<xs:attribute name="date" use="required" type="xs:date"/>
</xs:complexType>
</xs:element>
</xs:schema>

5.2 Testcase Variations File

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

xmlns:conf
="http://xbrl.org/2008/conformance"
targetNamespace="http://xbrl.org/2008/conformance" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="testcase">
<xs:complexType>
<xs:sequence>
<xs:element ref="conf:creator"/>
<xs:element name="number" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
<xs:element ref="conf:description"/>
<xs:element ref="conf:reference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="conf:variation" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="creator">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="description" type="xs:string"/>
<xs:element name="reference">
<xs:complexType>
<xs:attribute name="specification" type="xs:string"/>
<xs:attribute name="id" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:element name="variation">
<xs:complexType>
<xs:sequence>
<xs:element ref="conf:creator" minOccurs="0"/>
<xs:element name="number" type="xs:string" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element ref="conf:description"/>
<xs:element ref="conf:reference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="conf:data"/>
<xs:element ref="conf:result"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="data">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element ref="conf:schema"/>
<xs:element ref="conf:linkbase"/>
<xs:element ref="conf:instance"/>
<xs:element ref="conf:parameter"/>
<xs:element ref="conf:filter"/>
<!-- some cases need this in the data section instead of in the results. -->
<xs:element name="versioningReport" type="conf:versioningReportType"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="schema" type="conf:inputFileType"/>
<xs:element name="linkbase" type="conf:inputFileType"/>
<xs:element name="instance" type="conf:inputFileType"/>
<xs:complexType name="inputFileType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="id" type="xs:ID" use="optional"/>
<xs:attribute name="readMeFirst" type="xs:boolean" use="optional" default="false"/>
<xs:attribute name="dts" type="conf:fromTo" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="parameter">
<xs:complexType>
<xs:attribute name="name" type="xs:QName"/>
<xs:attribute name="datatype" type="xs:QName"/>
<xs:attribute name="value" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:element name="filter">
<xs:complexType>
<xs:attribute name="file" type="xs:IDREF"/>
<xs:attribute name="id" type="xs:IDREF"/>
</xs:complexType>
</xs:element>
<xs:complexType name="versioningReportType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="readMeFirst" type="xs:boolean" use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="result">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="assertionTests">
<xs:complexType>
<xs:attribute name="assertionID" type="xs:string"/>
<xs:attribute name="countSatisfied" type="xs:integer"/>
<xs:attribute name="countNotSatisfied" type="xs:integer"/>
</xs:complexType>
</xs:element>
<xs:element name="filterTest" type="xs:string"/>
<xs:element name="instance" type="xs:anyURI"/>
<xs:element name="versioningReport" type="xs:anyURI"/>
<xs:element name="error" type="xs:QName"/>
</xs:choice>
<xs:attribute name="expected" use="optional">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="valid"/>
<xs:enumeration value="invalid"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:simpleType name="fromTo">
<xs:restriction base="xs:string">
<xs:enumeration value="from"/>
<xs:enumeration value="to"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

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

7 Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix A Document history (non-normative)

DateAuthorDetails
06 October 2011Roland Hommes

Initial version.

12 October 2011Hugh Wallis

Conversion to S4S and some rephrasing.

16 October 2011Herm Fischer

Updated Section 2.2 for consumption to note that testing for consumption is a process which validates reports to detect errors, where noted, and validates reports not containing errors to show they detect no errors. Added Section 4 and Section 5. Added paragraph in Section 2.3 on relative URI use in all test case files (amongst themselves and relative to versioning schema files).

Appendix B Errata corrections 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 Versioning Working Group up to and including 19 October 2011. 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.

No errata have been incorporated into this document.