The Canonical Text Services Protocol test suite and validator

Overview

The CTS 3 test suite is comprised of a sample data set of texts and a TextInventory file describing them; a set of test requests to apply to the sample data set; and a set of files with valid responses to the test requests. This test suite can be used to test a CTS implementation's compliance with the protocol.

The CTS validator is a a servlet that uses the test suite to test a CTS installation.

Format of the tests

Tests are defined in a simple XML file that can be easily understood from an example: 

<test id="05">
<description>Request on valid notional work.</description>
<request>GetValidReff</request>
<urn>urn:cts:greekLit:tlg0013.tlg011</urn>
<otherparams/>
</test>

A brief summary of the test is given in a description element. The CTS request to be tested and the required URN parameter are given in the request and urn elements, respectively ; if other parameters are required, they may be supplied as HTML parameter strings in name=value format within the otherparams element.

Each test is identifed with an @id attribute; a valid reply is stored in a a corresponding .xml file with the same base name as the @id attribute. For the above example, the valid test results are in a file named 05.xml

Meaning of the tests

Programs to assess the tests properly need to recognize what parts of the sample valid replies are required by the CTS protocol (and so may be directly compared with the actual reply obtained from a CTS installation to test), and what parts are left open for implementations to use in different ways. Generally, there are three distinct cases:

  1. cases testing a CTS error. In these cases, the code element of the root CTSError element should always be identical in both actual and expected XML.
  2. a valid reply to a GetCapabilities request: comparison of the actual vs. expected response is complex because CTS installations are free to use the @docname attribute of the online element in any way they choose: its value is not defined and therefore cannot be tested.
  3. Valid replies to all other requests: the reply elements of the actual and expected XML should be identical, in XML terms. Tests for equality must respect all XML conventions that affect comparison: XML conventions about white space, undefined order of attributes, etc.

The ctsvalidator servlet

ctsvalidator is a servlet written in groovy+java that reads through the test suite and applies all its tests to a CTS installation identified by a URL. It is available from the project sourceforge site both as a precompiled war file that you can drop into a servlet container, and as groovy source code (with included java libraries).

Status

Download