Copyright ©2011 XBRL International Inc., All Rights Reserved.
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.
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)
A Document history (non-normative)
B Errata corrections in this document
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.
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.
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:
ver:assignment content for any change found. Be aware that some of the events CAN have multiple reasons for changing.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 |
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).
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:
ver:assignment/@id and ver:action/@id carry random values; the ver:assignmentRef/@ref
needs to link the appropriate @id on the ver:assignment.
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).
conceptAdd
and conceptDelete have events been grouped into a single action.
ver:assignmentRef nodes or the ver:assignment contains two categories.
Both are valid options. Test cases use only the latter one.
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.
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.
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.
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).
| Date | Author | Details |
|---|---|---|
| 06 October 2011 | Roland Hommes |
Initial version. |
| 12 October 2011 | Hugh Wallis |
Conversion to S4S and some rephrasing. |
| 16 October 2011 | Herm 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). |
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.