CCXML 1.0 Implementation Report

Version: 12 April 2011

Contributors:

RJ Auburn, Voxeo
Paolo Baggia, Loquendo (Chief Editor)
Marina Berati, Loquendo
Serguei Golberg, Voxeo
Rob Green, Voxeo
Fenton Har, Genesys
Matthew Prast, Voxeo
Laura Ricotti, Loquendo

Copyright ©2011 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, and document use rules apply.

---

Table of Contents

• 1. Introduction
  • 1.1 Implementation Report Objectives
  • 1.2 Implementation Report Non-objectives
• 2. Work During the Candidate Recommendation Period
• 3. Participating in the Implementation Report
• 4. Entrance Criteria for the Proposed Recommendation phase
• 5. Implementation Report Requirements
  • 5.1 Detailed requirements for Implementation Report
  • 5.2 CCXML Processor Coverage
  • 5.3 Notes on Testing
  • 5.4 Out of Scope
• 6. Systems
• 7. Test Results
• Appendices
• Appendix A. Test Assertion XML API Definition
  • A.1 API Definition
    • A.1.1 Test inizializations
    • A.1.2 Test setup
    • A.1.3 Intermediate status indicators
    • A.1.4 Remote side operations
    • A.1.5 Final status indicators
    • A.1.6 Helper functions
    • A.1.7 Uncondition Exit Expr
  • A.2 Simple test examples
  • A.3 Jumbo test example
  • A.4 XML Schema
  • A.5 XSLT Template Definition
  • A.6 Transforming tests with XSLT
• Appendix B. Abstract CGI (IRCGI) API definition
  • B.1 Processing Model
  • B.2 Syntax
  • B.3 Document Type Definition
  • B.4 Test examples
  • B.5 Usage
  • B.6 Transformation requirements
  • B.7 Reference XSLT documents
  • B.8 Test developer requirements
  • B.9 Web server administrator requirements
• Appendix C. Downloading Tests
  • C.1 The Manifest
  • C.2 The Assertion Manifest
  • C.3 The Report SubmissionTemplate
  • C.4 The Stylesheet
• Appendix D. Acknowledgements
• Appendix E. Changes from the previous version

1. Introduction

The CCXML 1.0 Specification entered the Candidate Recommendation period on 1 April 2010.

Preparation of an Implementation Report is a key criterion for moving beyond the Candidate Recommendation phase. This document describes the requirements for the Implementation Report and the process that the Voice Browser Working Group will follow in preparing the report.

The revised target date for entering Proposed Recommendation is 3 August 2010. The group will advance CCXML 1.0 to Proposed Recommendation no sooner than 3 August 2010.

Note: This Implementation Report was modified based on the public comments. See Appendix E for the detail of the changes.

1.1 Implementation Report Objectives

1. Must verify that the specification is implementable.
2. Must demonstrate interoperability of implementations of the specification.

1.2 Implementation Report Non-objectives

1. The IR does not attempt conformance testing of implementations.

2. Work During the Candidate Recommendation Period

During the CR period, the Working Group will carry out the following activities:

1. Clarification and improvement of the exposition of the specification.
2. Disposing of Comments that were communicated to the WG during the CR period.
3. Preparation of an Implementation Report meeting the criteria outlined in this document.

3. Participating in the Implementation Report

You are invited to contribute to the assessment of the W3C CCXML 1.0 Specification by participating in the Implementation Report process.

• Deadline for submission of a CCXML Implementation Report is 28 July 2010.
• All the tests reported in the table below and in the report submission format are provided with this document. The whole test suite including the report submission format is also contained in ccxml10-ir-20110412.zip
• Comments on this document and the test suite or requests for further information should be sent to the Working Group's public mailing list www-voice@w3.org (archive). If an updated version of this document or the test set is published, a notification will be sent to this mailing list.

4. Entrance Criteria for the Proposed Recommendation Phase

The Voice Browser Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:

1. Sufficient reports of implementation experience have been gathered to demonstrate that CCXML processors based on the specification are implementable and have compatible behavior.
2. Specific Implementation Report Requirements (outlined below) have been met.
3. The Working Group has formally addressed and responded to all public comments received by the Working Group.

5. Implementation Report Requirements

5.1 Detailed requirements for Implementation Report

1. Testimonials from implementers will be included in the IR when provided to document the utility and implementability of the specification.
2. IR must cover all specified features in the specification. For each feature the IR should indicate:
   • Feature status: required, optional, other
   • Feature utility/usefulness based on feedback from implementers
   • Implementability of the feature specification
   • Interoperability of multiple implementations of the feature
3. Feature status is a factor in test coverage in the report:
   • Required specification features must have at least two implementations. Implementations that do not implement a required specification feature must document the reason for not implementing the feature.
   • Optional specification features must have at least one implementation. Implementations that do not implement an optional specification feature should document the reason for not implementing.

5.2 CCXML Processor Coverage

Require implementations and testimonial statements for at least two CCXML platforms.

5.3 Notes on Testing

1. A test report must indicate the outcome of each test assertion. Possible outcomes are "pass", "fail" or "not-impl". "pass" requires output of the CCXML processor that is equivalent to the output specified in the respective test file. A report must document the way test output was verified. "not-impl" means the CCXML processor has not implemented the specific feature required by a test.
2. A test report may contain an additional comment for each test. If a test fails, a comment should be added (see also Detailed requirements for Implementation Report).
3. Every attempt has been made to keep the tests language-neutral through the use of the Test API described in Appendix A and Appendix B.
4. Each test is a Jumbo test as described in Appendix A.3, which tests several test assertions in a single test.
5. Some tests contain notes that should be read before executing them. These notes can be found in comments contained within the main test document and preceding the test code.

5.4 Out of Scope

1. IR will not cover CCXML processor performance.
2. IR will not cover VoiceXML processor recognition performance.
3. IR will not validate that a completely conformant ECMA script implementation has been done.

6. Systems

Interact Incorporated SPOT SIP Engine

Executive Summary

Interact Inc. Software Systems, a privately held company in the IVR space for more than 20 years, delivered our first W3C standards based product in 2004. Our first implementation of CCXML was based on the 29 Jun 2005 Working Draft, which we have subsequently used in conjunction with our high performance SPOT SIP Engine and VIP line of IVR products. We have waited patiently since then for a Candidate Recommendation, since that draft and subsequent drafts left many open questions. With the W3C CCXML 1.0 Candidate Recommendation, we now have a more complete and quite well documented interface to call control, switching, and conferencing. Interact Incorporated is proud to submit our Implementation Report. As a company not part of the W3C, and therefore not part of the specification development process, our report represents an outsider viewpoint of its feasibility and usefulness.

Loquendo VoxNauta CCXML Interpreter

Executive Summary

As a leading player in the speech technologies and voice platform markets, Loquendo believes that the CCXML 1.0 Specification increases the possibilities for the development of a wide range of voice applications by simplifying and enhancing call control management. The availability of the CCXML standard completes the tremendous leap forward made by VoiceXML, and in general the Speech Interface Framework developed by the W3C Voice Browser working group, allowing a clear separation between service and control layers. CCXML 1.0 will further promote the creation of efficient and powerful voice applications and it will hopefully further boost the IVR market and speech market in general.

Loquendo is delighted to contribute by submitting the CCXML 1.0 Implementation Report, which clearly demonstrates the effectiveness of the CCXML specification. Loquendo will continue to strongly support the activities of the W3C Voice Browser and Multimodal Interaction as part of its commitment to actively contributing to the evolution of their standards.

OptimTalk CCXML interpreter

Executive Summary

OptimSys provides software technologies, products and services in the area of telephony, call centers, IVR systems and speech-enabled systems in general. The company specializes in VoiceXML, CCXML and advanced speech technologies.

We are strongly convinced that the CCXML specification plays an irreplaceable role in creation of value added services for telephony, going far beyond the traditional telecom and call center market segments.

Besides these areas, OptimSys also uses CCXML, in combination with VoiceXML, for integration of telephony with business processes and corporate IT systems, or for building advanced communication systems featuring automation for dispatch terminals.

The CCXML interpreter became an important part of OptimSys' OptimTalk platform. Our first implementation was based on the April 30, 2004 Working Draft and since then OptimSys continuously contributes to the CCXML specification development as an external contributor. We are happy to see it becoming mature.

This report contains final CCXML Implementation results for OptimTalk CCXML interpreter. It demonstrates the implementability and interoperability of CCXML 1.0 specification.

Voxeo Prophecy 10.2

Executive Summary

Voxeo is pleased to be able to announce 100% support for the W3C Call Control XML (CCXML) 1.0 specification. As the company that delivered the world first and now the the worlds most compliant CCXML platform we are happy to announce our continued support and commitment to the CCXML specification. Our CCXML implementation is used by over 200,000 companies to power billions of phone calls per year as part of our worldwide hosting network and our on-premise platform. For more information about our platform please visit our web site at www.voxeo.com.

7. Test Results

The following table lists all the assertions that were derived from the CCXML 1.0 Specification.

The Assert ID column uniquely identifies the assertion, which is linked to the start test. Note that some test assertions are tested in depending documents.

The Spec column identifies the section of the CCXML 1.0 Specification from which the assertion was derived.

The Conformance column indicates whether or not the CCXML 1.0 Specification requires the CCXML processor to implement the feature described by the test assertion.

The Test Type column indicates whether or not the associated test requires an adaptation to the testing environment. If the test assertion is considered manual, then the notes of the associated test gives more details about how the test must be modified (see Appendix A.1).

License

This test suite is licensed under both the W3C Test Suite License and the W3C 3-clause BSD License. See W3C Legal's explanation of the licenses.

Appendices

Appendix A - Test Assertion XML API Definition

This appendix describes a framework for authoring CCXML tests. The framework abstracts the markup used to define interactions with the user, allowing vendors to use their own test infrastructure by applying an XSLT transformation to the test source. Modifications to the test infrastructure should require a change to the XSLT template only followed by re-transformation of the test source.

The appendix is divided into the following sections:

• A.1 API Definition
• A.2 Simple test examples
• A.3 Jumbo test example
• A.4 XML Schema
• A.5 XSLT Template Definition
• A.6 Transforming tests with XSLT

A.1 API definition

The test API described in this document uses the complete schema specified in the CCXML 1.0 specification with the addition of a set elements in their own namespace "http://www.w3.org/2005/ccxml-conformance" that greatly simplify the process of authoring tests and abstract the implementation details of the testing infrastructure. The elements are divided into the following categories:

• A.1.1 Test inizializations
• A.1.2 Test setup
• A.1.3 Intermediate status indicators
• A.1.4 Remote side operations
• A.1.5 Final status indicators
• A.1.6 Helper functions
• A.1.7 Uncondition Exit Expr

A.1.1 Test inizializations

These elements are used to inizialize the test environment.

docsetup

This element must be the first child of <ccxml> and is used to inizialize the test environment making available the ECMA script variables that represent:

• the event processor state variable;
• parameters passed to the XSL;
• support variables (address/phone numbers and timeouts to be used for outbound calls, dialog URIs, etc.).
• support variable for running the testing framework

Support variables values should be instantiated in the actual XSLT template and should be used as read-only.
The element sets the following ECMA expression:

current_state	Event processor state variable. It is initialized to init.
TEST_CREATECALL_DEST_NOANSWER	Outcall destination that does not answer.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE1	Outcall destination that answers #1.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE2	Outcall destination that answers #2.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE3	Outcall destination that answers #3.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE4	Outcall destination that answers #4.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE5	Outcall destination that answers #5.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE6	Outcall destination that answers #6.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE7	Outcall destination that answers #7.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE8	Outcall destination that answers #8.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE9	Outcall destination that answers #9.
TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE10	Outcall destination that answers #10.
TEST_CREATECALL_DEST_ANSWER_AND_DISCONNECT_SHORT	Outcall destination that answers and disconnects short.
TEST_CREATECALL_DEST_ANSWER_AND_FAIL_JOIN	Outcall destination that answers and fails to join.
TEST_SHORT_TIMEOUT	Short timeout intialized to '10s'
TEST_LONG_TIMEOUT	Long timeout initialized to '30s'.
TEST_VERY_LONG_TIMEOUT	Very long timeout initialized to '150s'.
ASSERTION_NUM	Assertion number. assertnum parameter passed to the XSL.
SETUP_CONNECTION_TYPE	Type of setup connection. connectiontype parameter passed to the XSL.
TEST_BASIC_HTTP_URI	Basic HTTP URI. Not used in this release.
TEST_IR_URI	IR site URI.
TEST_ABSOLUTE_URI	Absolute URI. Not used in this release.
uri_UNREACHEABLE	A URI unreacheable.

Other variable declared in this part of the XSLT must not be changed because they are part of the framework.

A.1.2 Test setup

These elements are used to setup the test.

setup

This element must be the first child of <eventprocessor> and is used to set what kind of call starts the test:

• connected call is an implicit accepted call, so both ccxml.loaded and connection.alerting events are catched and <accept> is executed; also connection.signal is implicity catch; the first event processed in tests will be connection.connected;
• alerting call implicitly catches ccxml.loaded event so the first event processed in tests will be connection.alerting;
• noconnection call means that no implicit catch is done so the first event processed in tests will be ccxml.loaded.

The type of setup is supplied to the XSL as the connectiontype parameter, mapped into the SETUP_CONNECTION_TYPE ECMA script variable.

A.1.3 Intermediate status indicators

These elements may be used to signal intermediate results or indications.

comment

Specifies intermediate results or indications as stated in the mandatory expr attribute:

expr	It contains the ECMA expression related to the intermediate information.

A.1.4 Remote side operations

These elements are used to drive remote side operations. Not used for the current implementation of the framework.

remotedisconnect

Invoke the remote side hang-up. The element supports the following attributes:

connectionid	An ECMAScript expression that evaluates to the identifier of the connection on which the hang-up is invoked.

A.1.5 Final status indicators

These elements are used to signal the completion of a test.

pass

Indicates successful test completion.

fail

Indicates unexpected results from the interpreter.

not_exec

Indicates tests not executed. The element supports the following optional attributes:

event	Optional. Event that caused failure.
reason	Optional. An ECMAScript expression that evaluates to a string at run-time providing information about the probable cause for failure.

A.1.6 Helper functions

These elements provide helper functions to automate common tasks. Not used for the current implementation of the framework.

check-event-name

Check the presence and the correctness of the name attribute of the event. The element supports the following attributes:

event	An ECMAScript expression that evaluates to the event to check.
value	An ECMAScript expression that evaluates to the name of the event.

A.1.7 Unconditional Exit Expr

These elements may be used to exit unconditional with a mandatory output comment.

uncond_exit

Specifies final comment as stated in the mandatory expr attribute:

expr	An ECMAScript expression that evaluates to a string at run-time providing information about the unconditional exit information.

A.2 Simple test examples

The following examples illustrate a simple use of the proposed tags. These examples were written to help validate the stylesheet, but not directly used to generate the tests. The current implementation of CCXML Implementation Report framework all the tests were based on Jumbo test, see Appendix A.3 for details.

Example 1

The following example tests that a connection.disconnected event is received when a <disconnect/> element is run. This test assumes that a connection of type connected is delivered as part of the execution of the <conf:setup/> element.

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
   xmlns:conf="http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>

  <eventprocessor statevariable="current_state">
    <conf:setup/>

    <transition event="connection.connected">
      <disconnect/>
    </transition>

    <transition event="connection.disconnected">
      <conf:pass/>
    </transition>

    <transition event="*">
      <conf:fail/>
    </transition>
  </eventprocessor>
</ccxml>

Example 2

The following example tests that a connection.disconnected event is received when the remote side hangs up. This test assumes that a connection of type connected is delivered as part of the execution of the <conf:setup/> element.

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
   xmlns:conf="http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>

  <eventprocessor statevariable="current_state">
    <conf:setup/>

    <transition event="connection.connected">
      <conf:remotedisconnect/>
    </transition>

    <transition event="connection.disconnected">
      <conf:pass/>
    </transition>

    <transition event="*">
      <conf:fail reason="'Unexpected Event ' + event$.name"/>
    </transition>
  </eventprocessor>
</ccxml>

Example 3

The following example tests that a connection.failed event is received when a call to a phone number that does not answer is placed. This test assumes that a connection of type noconnection is delivered as part of the execution of the <conf:setup/> element.

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
   xmlns:conf="http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>

  <eventprocessor statevariable="current_state">
    <conf:setup/>
    
    <transition event="ccxml.loaded">
      <createcall
             dest="TEST_CREATECALL_DEST_NOANSWER"
             timeout="TEST_LONG_TIMEOUT"/>
    </transition>

    <transition event="connection.progressing">
      <conf:comment expr="event$.name + ' received'"/>
    </transition>

    <transition event="connection.failed">
      <!-- Check timestamps to have TEST_LONG_TIMEOUT to get here -->
      <conf:pass/>
    </transition>

    <transition event="*">
      <conf:fail reason="'Unexpected Event ' + event$.name"/>
    </transition>
  </eventprocessor>
</ccxml>

Example 4

The following example tests that a connection.connected event is received when a call to a phone number that answers is placed. This test assumes that a connection of type noconnection is delivered as part of the execution of the <conf:setup/> element.

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
   xmlns:conf="http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>

  <eventprocessor statevariable="current_state">
    <conf:setup/>
    
    <transition event="ccxml.loaded">
      <createcall
            dest="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE1"
            timeout="TEST_SHORT_TIMEOUT"/>
    </transition>

    <transition event="connection.progressing">
      <conf:comment expr="event$.name + ' received'"/>
    </transition>

    <transition event="connection.connected">
      <conf:pass/>
    </transition>

    <transition event="*">
      <conf:fail reason="'Unexpected Event ' + event$.name"/>
    </transition>
  </eventprocessor>
</ccxml>

Example 5

The following example tests that a connection.connected event is received when a call to a phone number that answers is placed. This is the same as example 4 but just shows how it is possible to use a different phone number to get some other action on the remote side. This test assumes that a connection of type noconnection is delivered as part of the execution of the <conf:setup/> element.

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
   xmlns:conf="http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>

  <eventprocessor statevariable="current_state">
    <conf:setup/>
    
    <transition event="ccxml.loaded">
      <createcall
           dest="TEST_CREATECALL_DEST_ANSWER_AND_DISCONNECT_SHORT" 
           timeout="TEST_SHORT_TIMEOUT"/>
    </transition>

    <transition event="connection.progressing">
      <conf:comment expr="event$.name + ' received'"/>
    </transition>

    <transition event="connection.connected">
      <conf:pass/>
    </transition>

    <transition event="*">
      <conf:fail reason="'Unexpected Event ' + event$.name"/>
    </transition>
  </eventprocessor>
</ccxml>

Example 6

The following example tests that a conference.joined event is received when two connections are joined by means of <join/> element. This test assumes that a connection of type connected is delivered as part of the execution of the <conf:setup/> element.

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
   xmlns:conf="http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>

  <var name="firstConnection"/>
  <var name="secondConnection"/>

  <eventprocessor statevariable="current_state">
    <conf:setup/>

    <transition event="connection.connected" state="init">
      <assign name="current_state" expr="'connected'"/>
      <assign name="firstConnection" expr="event$.connectionid"/>
      <createcall
           dest="TEST_CREATECALL_DEST_ANSWER_AND_DISCONNECT_SHORT"
           connectionid="secondConnection"
           timeout="TEST_SHORT_TIMEOUT"/>
    </transition>

    <transition event="connection.progressing">
      <conf:comment expr="event$.name + ' received'"/>
    </transition>

    <transition event="connection.connected" state="connected">
      <join id1="firstConnection" id2="secondConnection"/>
    </transition>

    <transition event="conference.joined">
      <conf:pass/>
    </transition>

    <transition event="*">
      <conf:fail reason="'Unexpected Event ' + event$.name"/>
    </transition>
  </eventprocessor>
</ccxml>

Example 7

The following example tests that a connection.connected event is received when the <accept/> element is executed. This test assumes that a connection of type alerting is delivered as part of the execution of the <conf:setup /> execution.

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml"
    xmlns:conf=">http://www.w3.org/2005/ccxml-conformance">

  <conf:docsetup/>
  <eventprocessor statevariable="current_state">  
    <conf:setup/>

    <transition event="connection.alerting">   
      <conf:comment expr="'Received ' + event$.name"/>
      <accept connectionid="event$.connectionid"/>
      <conf:comment
          expr="'Executed accept on connection ' + event$.connectionid"/>    
    </transition>
    
    <transition event="connection.connected">    
      <conf:comment expr="'Received ' + event$.name"/>
      <conf:pass/>    
    </transition>

    <transition event="*">    
      <conf:fail reason="'Unexpected Event ' + event$.name"/>    
    </transition>
  </eventprocessor>
</ccxml>

A.3 Jumbo test examples

This section will brefly describe the structure of a Jumbo test.

All the current tests are developed as Jumbo test, so that a single test document is able to test more than one test assertions. In Appendix C.1, the Manifest describes the association of all the test assertions in Section 7 and the corresponding Jumbo test.

In the initial part there is a "prelude", which is contained in a script element after <conf:docsetup/>. The most important function of this prelude is to initialize an "assertion queue", which contains all of the parent assertions in the Jumbo test. Each of which has its own unit test. "child" assertions are related to parent assertions, and appear inside of their parent's unit test. In the example the parent assertion is "17" and the children are: "12", "16", "17".

The Jumbo test loops on the parent assertions, by means of the "user.PREPARE_NEW" event. So the test starts when in an initial transition (depending on the test assertions to be tested either in the "connection.alerting", "connection.connected") the event "user.PREPARE_NEW" is sent. At that point the loop is started and the Pass or Fail assertions are recorded. During the loop the state variable is set to "ASSERTION_NMBR_#" of each of the parent assertions and the transitions with that state variable are the ones devoted to that assertion. During the loop the assertions passed or failed are reported, and after the last assertion the loop finishes and the session ends.

Example of a Jumbo test

<?xml version="1.0" encoding="UTF-8"?>
<ccxml xmlns="http://www.w3.org/2002/09/ccxml"
       xmlns:conf="http://www.w3.org/2005/ccxml-conformance"
       version="1.0">
<!--
Serguei's infrastructure performs a loop on the 'assertions' Ecma array,
based on "name_prepare_new" event for doing the "loop".

Mainly we have to different levels of assertions: 

- Main assertions, stored in 'assertions' array
- Children assertions, stored into 'assert_trace'

An assertion is a child assertion if it does not need to perform any action,
but it is sufficient to test its father assertion result to determine 
if it passes or fails.

The test finishes when all the main assertions have been tested. 
Children assertions are tested after the father itself.

If an unexpected event is caught by the <transition event"*"/> a comment
is printed and the loop continues with the next iteration.

An hang up event causes the interruption of test: session exits.

All the send.successful events are caught and ignored (they are generated
by the loop mechanism).
-->

  <conf:docsetup/>

  <var name="myFetchID"/>

  <var name="first_accept_ok"/>
  

  <script><![CDATA[
    var i=0;
  
    assertions[i++] = init_assertion('17');  
   
    var assert_last = i - 1;
    var assert_index = -1;
    //
    // out of the loop assertions (children)

    // Children of 17
    add_2_assert_trace('12');
    add_2_assert_trace('16');
    add_2_assert_trace('15');

    s_ASSERTIONS_LEFT = show_remained_assertions();
    var b_in_test = false;
  ]]></script>
 
 
  <eventprocessor statevariable="current_state">
    <conf:setup type="noconnection"/>

    <transition event="ccxml.loaded" state="init">
      <conf:comment expr="'Event: ' + event$.name"/>  
    </transition>
    
    <transition event="connection.alerting" state="init">
      <send targettype="'ccxml'" target="session.id" name="'user.timeout'"
            delay="TEST_LONG_TIMEOUT"/>
      <assign name="first_accept_ok" expr="false"/>
      <var name="hints" expr="new Object()"/>
      <assign name="hints.test" expr="'test'"/>
            <accept hints="hints"/>
    </transition>
    <transition event="connection.connected" state="init">
      <conf:comment expr="'Event: ' + event$.name"/>
      <assign name="first_accept_ok" expr="true"/>   
      <send targettype="'ccxml'" target="session.id" name="name_prepare_new"/>
    </transition>

    <transition event="user.PREPARE_NEW">
      <conf:comment expr="'Event: ' + event$.name"/>
      <if cond="assert_index >= 0">
        <assign name="ASSERTION_NUM" expr="assertions[assert_index].number"/>
        <assign name="t_ASSERT_RESULT" expr="assertions[assert_index].P_F"/>
        <script>assertions[assert_index].reason = t_ASSERT_REASON;</script>
      <if cond="t_ASSERT_RESULT == s_PASS">
        <conf:pass reason="t_ASSERT_REASON"/>
      <elseif cond="t_ASSERT_RESULT == s_FAIL"/>
        <conf:fail reason="t_ASSERT_REASON"/>
      <else/>
        <conf:not_exec reason="t_ASSERT_REASON"/>
      </if>
    </if>
    <assign name="assert_index" expr="assert_index + 1"/>
    <if cond="assert_index > assert_last">
      <log label="s_TA" expr="s_ASSERTIONS_LEFT"/>
      <conf:uncond_exit expr="'DONE'"/>
    <else/>
      <log label="s_TA" expr="s_ASSERTIONS_LEFT"/>
      <assign name="ASSERTION_NUM" expr=" assertions[assert_index].number"/>
      <assign name="t_ASSERT_REASON" expr="''"/>
      <script>assertions[assert_index].P_F = s_FAIL;</script>
      <assign name="current_state" expr="state_prefix + ASSERTION_NUM"/>
      <send targettype="'ccxml'" target="session.id"
            name="start_name_prefix + ASSERTION_NUM"/>
    </if>
  </transition>

              
<!--
17.
If the attribute value is invalid or there is no valid default value,
an error.semantic event must be thrown

12.
The execution of an <accept> MUST cause the underlying platform 
to signal the telephony system to connect the specified Connection 
to the CCXML platform. 

16.
If the connectionid attribute is omitted, the interpreter must accept 
using the id indicated in the current event being processed.
-->

    <transition event="user.START_ASSERTION_17" state="ASSERTION_NMBR_17">  
      <conf:comment
        expr=" 'Current state : ' +current_state+ ' , Event: ' + event$.name"/>     

      <!-- Begin Related Tests -->
      <if cond="first_accept_ok">
        <assign name="ASSERTION_NUM" expr="'12'"/>  
        <conf:pass/>
        <assign name="ASSERTION_NUM" expr="'16'"/>  
        <conf:pass/>
        <assign name="ASSERTION_NUM" expr="'15'"/>  
        <conf:pass/>    
      <else/>
        <assign name="ASSERTION_NUM" expr="'12'"/>  
        <conf:fail/>
        <assign name="ASSERTION_NUM" expr="'16'"/>  
        <conf:fail/>
        <assign name="ASSERTION_NUM" expr="'15'"/>  
        <conf:fail/>    
      </if>
      <!-- End Related Tests -->
    
      <accept/>
    </transition>

    <transition event="error.semantic" state="ASSERTION_NMBR_17">  
      <conf:comment 
        expr=" 'Current state : ' +current_state+ ' , Event: ' + event$.name"/>  
      <script>assertions[assert_index].P_F = s_PASS;</script>     
      <send targettype="'ccxml'" target="session.id" name="name_prepare_new"/>
    </transition>
    
    <transition event="error.*" state="ASSERTION_NMBR_17">  
      <conf:comment 
        expr=" 'Current state : ' +current_state+ ' , Event: ' + event$.name"/>  
      <script>assertions[assert_index].P_F = s_FAIL;</script>     
      <assign name="t_ASSERT_REASON" expr="'error.semantic expected' "/>
   <send targettype="'ccxml'" target="session.id" name="name_prepare_new"/>
    
    </transition>

 <!--  ***************** COMMON ******************************** -->
    <transition event="send.successful">
    </transition>

    <transition event="user.timeout">
      <assign name="current_state" expr="'GEN'"/>
      <conf:uncond_exit expr="'TEST-TIMEOUT.' + show_remained_assertions()"/>
    </transition>
  
    <transition event="connection.disconnected">
      <conf:uncond_exit expr="'CONNECTION-DISCONNECTED'"/>
    </transition>
 
    <transition event="*">
      <assign name="t_ASSERT_REASON"
        expr="'UNEXPECTED EVENT ' + event$.name + ' IN STATE ' + current_state"/>
      <conf:comment expr="t_ASSERT_REASON"/>
      <if cond="current_state == 'init'">
        <conf:uncond_exit expr="'Did not come out from init state.'"/>
      <else/>
        <send targettype="'ccxml'" target="session.id" name="name_prepare_new"/>
      </if>   
    </transition>
 
  </eventprocessor>
</ccxml>

A.4 XML Schema

The following XML Schema succintly declares the Test API markup elements, their attributes, and the legal values for those attributes if applicable.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
         elementFormDefault="qualified">
  <xs:element name="docsetup"/>
  <xs:element name="setup"/>
  <xs:element name="pass"/>
  <xs:element name="fail">
    <xs:complexType>
      <xs:attribute name="event" type="xs:string" use="optional"/>
      <xs:attribute name="reason" type="ECMAScript.expression"
               use="optional"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="not_exec">
    <xs:complexType>
      <xs:attribute name="event" type="xs:string" use="optional"/>
      <xs:attribute name="reason" type="ECMAScript.expression"
               use="optional"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="comment">
    <xs:complexType>
      <xs:attribute name="expr" type="ECMAScript.expression"
               use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="remotedisconnect"/>
    <xs:complexType>
      <xs:attribute name="connectionid" type="ECMAScript.expression"
               use="required"/>
    </xs:complexType>
  <xs:element name="check-event-name">
    <xs:complexType>
      <xs:attribute name="event" type="xs:string" use="required"/>
      <xs:attribute name="value" type="ECMAScript.expression" 
               use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="assignXSLvar">
    <xs:complexType>
      <xs:attribute name="name" type="xs:string" use="required"/>
      <xs:attribute name="var" type="xs:string" use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="ECMAScript.expression">
    <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:element name="uncond_exit">
    <xs:complexType>
      <xs:attribute name="expr" type="ECMAScript.expression"
               use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

The XML Schema can be used to validate the testing documents, or to transform the test source through the XSLT, and validate the output against the CCXML 1.0 Schema.

A.5 Sample XSLT Template Definition

The following is the listing of the XSLT that can be used to transform the previous examples into a valid CCXML 1.0 document. This XSLT is part of the framework for CCXML Implementation Report.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 1998-2010 W3C (MIT, ERCIM, Keio), All Rights Reserved. See http://www.w3.org/Consortium/Legal/. -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                   xmlns:conf="http://www.w3.org/2005/ccxml-conformance"
                   xmlns="http://www.w3.org/2002/09/ccxml" version="1.0">
 <xsl:output cdata-section-elements="script" indent="yes"/>
 <!-- Assume assertion number is passed in -->
 <xsl:param name="assertnum"/>
 <xsl:param name="connectiontype"/>
 <!-- ############################################# -->
 <!-- D o c u m e n t   H e a d e r s               -->
 <!-- ############################################# -->
 <!-- Copy everything that doesn't match other rules -->
 <xsl:template match="/ | @* | node()">
  <xsl:copy>
   <xsl:apply-templates select="@* | node()"/>
  </xsl:copy>
 </xsl:template>
 <!-- strip comments -->
 <xsl:template match="comment()"/>
 <!-- ############################################# -->
 <!-- F i n a l   S t a t u s   I n d i c a t o r s -->
 <!-- ############################################# -->
 <!-- Success criteria -->
 <xsl:template match="conf:pass">
  <xsl:call-template name="conf-pass">
   <xsl:with-param name="reason" select="@reason"/>
  </xsl:call-template>
 </xsl:template>
 <xsl:template name="conf-pass">
  <xsl:param name="reason"/>
  <script>remove_from_assert_trace(ASSERTION_NUM);</script>
  <xsl:choose>
   <xsl:when test="$reason != ''">
    <log label="s_TA+ASSERTION_NUM" expr="s_PASS + {$reason}"/>
   </xsl:when>
   <xsl:otherwise>
    <log label="s_TA+ASSERTION_NUM" expr="s_PASS"/>
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>
 <!-- Failure criteria -->
 <xsl:template match="conf:fail">
  <xsl:call-template name="conf-fail">
   <xsl:with-param name="reason" select="@reason"/>
  </xsl:call-template>
 </xsl:template>
 <xsl:template name="conf-fail">
  <xsl:param name="reason"/>
  <script>remove_from_assert_trace(ASSERTION_NUM);</script>
  <xsl:choose>
   <xsl:when test="$reason != ''">
    <log label="s_TA+ASSERTION_NUM" expr="s_FAIL + {$reason}"/>
   </xsl:when>
   <xsl:otherwise>
    <log label="s_TA+ASSERTION_NUM" expr="s_FAIL"/>
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>
 <xsl:template match="conf:not_exec">
  <xsl:call-template name="conf-not_exec">
   <xsl:with-param name="reason" select="@reason"/>
  </xsl:call-template>
 </xsl:template>
 <xsl:template name="conf-not_exec">
  <xsl:param name="reason"/>
  <xsl:choose>
   <xsl:when test="$reason != ''">
    <log label="s_TA+ASSERTION_NUM" expr="s_NOT_EXECUTED + {$reason}"/>
   </xsl:when>
   <xsl:otherwise>
    <log label="s_TA+ASSERTION_NUM" expr="s_NOT_EXECUTED"/>
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>
 <!-- ############################################# -->
 <!-- I n t e r m e d i a t e   R e p o r t s       -->
 <!-- ############################################# -->
 <!-- Copy everything doesn't match the other rules -->
 <xsl:template match="conf:comment">
  <log label="s_TA+ASSERTION_NUM" expr="'Comment: '+{@expr}"/>
 </xsl:template>
 <xsl:template match="conf:uncond_exit">
  <log label="s_TA" expr="{@expr} + '  EXIT.'"/>
  <exit/>
 </xsl:template>

 <!-- ############################################# -->
 <!-- Document Setup                                -->
 <!-- ############################################# -->
 <!-- Apply values to commonly used expressions -->
 <xsl:template match="conf:docsetup">
  <var name="s_NONE" expr="'NONE'"/>
  <var name="s_ASSERTIONS_LEFT"/>
  <script><![CDATA[
var trace_separator = ' ';
var assert_trace = new Object();;
function add_2_assert_trace(N){
assert_trace[N] = true;
}
function show_remained_assertions(){
var rr_ini = '';
var rr = rr_ini;
 var sIndex;
 for(sIndex in assert_trace ) {
  if( assert_trace[sIndex]){rr = rr + sIndex + trace_separator};
 }
 if (rr == rr_ini){rr = s_NONE;}
 return 'ASSERTIONS_LEFT: ' + rr;
}
function remove_from_assert_trace(N){
assert_trace[N] = false;
s_ASSERTIONS_LEFT = show_remained_assertions();
}
function init_assertion(N){
rr = Object()
rr.number = N;
rr.P_F = s_NOT_EXECUTED;
rr.reason = '';
rr.N_child = 0;
add_2_assert_trace(N);
return rr;
}
var a_tmp_1 = session.uri.split("\/");
var s_tmp_2 = a_tmp_1[a_tmp_1.length - 1];
var a_tmp_3 = s_tmp_2.split("\.");
var s_LOG_PREFIX = a_tmp_3[0]; 


]]></script>
  <var name="assertions" expr="Object();"/>
  <var name="current_state" expr="'init'"/>
  <var name="cur_event_ID"/>
  <var name="s_TA" expr="s_LOG_PREFIX + ' TA-'"/>
  <var name="s_PASS" expr="'PASS: '"/>
  <var name="s_FAIL" expr="'FAIL: '"/>
  <var name="s_NOT_EXECUTED" expr="'NOT_EXECUTED: '"/>
  <var name="state_prefix" expr="'ASSERTION_NMBR_'"/>
  <var name="name_prefix" expr="'user.ASSERTION_'"/>
  <var name="start_name_prefix" expr="'user.START_ASSERTION_'"/>
  <var name="name_prepare_new" expr="'user.PREPARE_NEW'"/>
  <var name="USER_ERROR" expr="'user.error'"/>
  <var name="TEST_CREATECALL_DEST_NOANSWER" expr="'sip:10.229.47.209'"/>
  <var name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE" expr="new Object();"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[0]" expr="'sip:10.229.47.209'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[1]" expr="'sip:10.229.47.111'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[2]" expr="'sip:10.229.47.209'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[3]" expr="'18005551004'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[4]" expr="'18005551005'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[5]" expr="'18005551006'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[6]" expr="'18005551007'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[7]" expr="'18005551008'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[8]" expr="'18005551009'"/>
  <assign name="TEST_CREATECALL_DEST_ANSWER_AND_STAY_ACTIVE[9]" expr="'18005551010'"/>
  <var name="TEST_CREATECALL_DEST_ANSWER_AND_DISCONNECT_SHORT" expr="'18005552000'"/>
  <var name="TEST_CREATECALL_DEST_ANSWER_AND_FAIL_JOIN" expr="'18005553000'"/>
  <var name="TEST_SHORT_TIMEOUT" expr="'10s'"/>
  <var name="TEST_LONG_TIMEOUT" expr="'30s'"/>
  <var name="TEST_VERY_LONG_TIMEOUT" expr="'150s'"/>
  <var name="ASSERTION_NUM" expr="'{$assertnum}'"/>
  <var name="SETUP_CONNECTION_TYPE" expr="'{$connectiontype}'"/>
  <var name="t_ASSERT_RESULT"/>
  <var name="t_ASSERT_REASON" expr="''"/>
  <var name="TEST_BASIC_HTTP_URI" expr="''"/>
  <var name="TEST_IR_URI" expr="'http://10.229.47.117:8080/W3C_CCXML_IR/output/'"/>
  <var name="TEST_ABSOLUTE_URI" expr="''"/>
  <var name="uri_UNREACHEABLE" expr="'http://10.255.255.254/unrea3chable'"/>

 </xsl:template>
 <!-- ############################################# -->
 <!-- Connection Setup                              -->
 <!-- ############################################# -->
 <!-- Setup the connection requested and handle appropriate events -->
 <xsl:template match="conf:setup">
        <xsl:call-template name="conf-setup">
            <xsl:with-param name="connectiontype" select="@type"/>
        </xsl:call-template>
 </xsl:template>
 
 <xsl:template name="conf-setup">
    <xsl:param name="connectiontype"/>
    <xsl:choose>
   <xsl:when test="$connectiontype = 'alerting'">
    <transition event="ccxml.loaded">
     <log label="s_TA+ASSERTION_NUM" expr="'Started: ' + event$.name"/>
     <!-- Insert script to initiate a call here -->
    </transition>
   </xsl:when>
   <xsl:when test="$connectiontype = 'connected'">
    <transition event="ccxml.loaded">
     <log label="s_TA+ASSERTION_NUM" expr="'Started: ' + event$.name"/>
     <!-- Insert script to initiate a call here -->
    </transition>
    <transition event="connection.signal" state="init">
     <log label="s_TA+ASSERTION_NUM" expr="'Received: ' + event$.name"/>
    </transition>
    <transition event="connection.alerting" state="init">
     <log label="s_TA+ASSERTION_NUM" expr="'Received: ' + event$.name"/>
     <accept connectionid="event$.connectionid"/>
     <log label="s_TA+ASSERTION_NUM" expr="'Accepted: ' + event$.connectionid"/>
    </transition>
   </xsl:when>
   <xsl:otherwise>
    <!-- type is "noconnection" or an invalid type -->
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>
 <!-- ############################################# -->
 <!-- Remote Disconnect                              -->
 <!-- ############################################# -->
 <!-- Instruct a remote agent to disconnect the specified connection -->
 <xsl:template match="conf:remotedisconnect">
  <log label="s_TA+ASSERTION_NUM"
     expr="'RemoteDisconnect: Please hang-up connection: ' + {@connectionid}"/>
 </xsl:template>
 <!-- ############################################# -->
 <!-- Helper Functions                              -->
 <!-- ############################################# -->
 <xsl:template match="conf:check-event-name">
  <if cond="!event$.name">
   <xsl:call-template name="conf-fail">
    <xsl:with-param name="reason">
     <xsl:text>'name property not defined'</xsl:text>
    </xsl:with-param>
   </xsl:call-template>
   <elseif cond="event$.name != '{@value}'"/>
   <xsl:call-template name="conf-fail">
    <xsl:with-param name="reason">
     <xsl:text>'name property should be' + </xsl:text>
     <xsl:value-of select="@value"/>
     <xsl:text> 'but is ' + event$.name </xsl:text>
    </xsl:with-param>
   </xsl:call-template>
   <else/>
   <xsl:call-template name="conf-pass"/>
  </if>
 </xsl:template>
</xsl:stylesheet>

A.6 Transforming tests with XSLT

Using the above mentioned stylesheets, the test ".txml" source documents can be transformed into ".ccxml" test documents. To accomplish this, a Java class is used. In the "bin directory there is a class called "TestGenerator". The script can run this manually to transform all of the tests and save them in a folder named "output". The "go.sh" and similarly "go.bat" example is the following:

#!/bin/sh

java -cp bin org.w3c.ccxml.ir.TestGenerator ./manifest.xml jumbo_test-ccxml-sample.xslt ircgi-2-jsp.xslt ./output

Note that to run the TestGenerator class, JDK version has to be 1.5 or higher. To check JDK version run:

java -version

Appendix B - Abstract CGI (IRCGI) API definition

The CCXML 1.0 Implementation Report contains assertions that require server-side support to verify HTTP headers and submitted values. To allow diverse test environments to use different server-side technologies, tests describe the server-side processing using a syntax independent of any particular server-side framework.

This appendix describes a server-agnostic XML API that can be transformed easily using XSLT into any server-side framework. Reference JSP XSLT templates is provided and used for running the framework.

The API supports the following:

• Verification of the method used to make the HTTP request (GET, POST, etc).
• Verification of the presence and value of one or more HTTP headers.
• Verification of the presence and value of one or more submitted parameters.
• Verification of the presence and value of method, headers, and parameters.
• Returning a specific HTTP response status code.
• Returning either a CCXML or a VoiceXML containing the reference to the next document to be visited.
• Sleeping for a specified number of seconds before returning a response.
• Setting an Expires response header based on a specified delta.

The XML API does not require the following:

• State management.
• Indicating test pass or failure.

B.1 Processing Model

A document conforming to this specification, heretofore referred to as an "IRCGI document", indicates the checks to be made on an HTTP request. Supported checks include:

• HTTP method
• Request headers
• Parameters

Checks may be nested. The result of the checks determines the next document to be executed. The next document must continue the test and must determine the success or failure of the test. Once the IRCGI document determines the next document, a response is sent, and the IRCGI document terminates.

B.2 Syntax

An IRCGI document consists of the following elements. The DTD can be found below.

ircgi

The root document element. This element must appear as the root document element for all IRCGI documents.

comment

Contains comments that may be accumulated during CGI execution. The comments may be returned in one or more log elements in the body of the HTTP response. This may be used as a primitive debugging facility.

if-header

Checks for the presence and value of an HTTP request header. Supports the following attributes:

name	Required. The name of the header. If only the name attribute is specified, the CGI must execute the if-header content only if the named header is present in the request.
value	Optional. The expected value of the header. If this attribute is specified, the CGI must execute the if-header content only if the named header is present in the request and its value matches that of the value attribute. This attribute and the starts-with attribute are mutually exclusive.
starts-with	Optional. The expected value with which the header begins. If this attribute is specified, the CGI must execute the if-header content only if the named header is present in the request and its value begins with the value of the starts-with attribute. This attribute and the value attribute are mutually exclusive.
ignore-case	Optional. The value match is case-sensitive if the ignore-case attribute is false, the default. The match is not case-sensitive if the attribute is true.

if-method

Checks the HTTP method used to submit request. The CGI must execute the if-method content only if the type attribute's value matches the HTTP method used to submit the request. The match is case-insensitive.

type	Required. The HTTP method: 'get' or 'post'.

if-parameter

Checks for the presence and value of an HTTP request parameter. Supports the following attributes:

name	Required. The parameter's name. If only the name attribute is specified, the CGI must execute the if-parameter content only if the named parameter is present in the request. This attribute and the starts-with attribute are mutually exclusive.
value	Optional. The parameter's expected value. If this attribute is specified, the CGI must execute the if-parameter content only if the named parameter is present in the request and its value matches that of the starts-with attribute. This attribute and the value attribute are mutually exclusive.
starts-with	Optional. The expected value with which the parameter begins. If this attribute is specified, the CGI must execute the if-parameter content only if the named parameter is present in the request and its value begins with the value of the starts-with attribute. This attribute and the value attribute are mutually exclusive.
ignore-case	Optional. The value match is case-sensitive if the ignore-case attribute is false, the default. The match is not case-sensitive if the attribute is true.

if-all-params

Checks for the presence and value of all HTTP request parameters against an expected set. Supports the following attribute:

ref	Required. The id of a params element containing the set of expected CGI parameters.

params

Defines a set of expected CGI parameters via one or more contained param elements. The params tag is allowed as a child of the root document element, ircgi.

id	Required. A unique identifier referenced by an if-all-params element.

param

Defines the name and value of an expected CGI parameter.

name	Required. The name of the CGI request parameter.
value	Required. The value of the CGI request parameter.

if-upload

Checks for the presence of a file upload. Supports the following attributes:

name

Required. The name of the parameter containing the uploaded bits. If only the name attribute is specified, the CGI must execute the if-upload content only if the named upload is present.

size

Optional. The expected size of the upload. If this attribute is specified, the CGI must execute the if-parameter content only if the named upload is present in the request and its size matches that of the value of the size attribute. The value of this attribute can be a static numeric value or a CGI parameter name. If a name is specified, the size of the file upload is compared to the value of the specified CGI parameter. The value of the CGI parameter must resolve to a numeric value. The size value should be specified in bytes.

next

Selects the next document either ".ccxml" or ".vxml" and, optionally, sets the HTTP response code. The CGI must generate a response upon executing a next element and must not execute any other elements.

code	Optional. The HTTP response code. If the code attribute is specified, its value must be used as the HTTP response status code. The default is 200 (Ok).
dest	Optional. The URL of the next document. If this attribute is specified, its value must be used by the response to designate the next document to be visited.
include	Optional. true or false If this attribute is true, the document specified by the dest attribute is returned as the result document. If this attribute is false, the default, the CGI returns a generated CCXML/VoiceXML document that contains a goto to the document specified by dest. The document generated when include is false may contain the content of comment elements that were encountered. Only files that are in the directory immediately above the cgi-bin directory (see below) may be included. Attempts to include other files result in an HTTP 403 (Forbidden) response status code.
isVXML	Optional. true or false If this attribute is true, the generated document is a VoiceXML 2.0 one. If this attribute is false, the default, the generated document is a CCXML 1.0 one.
sleep	Optional. An interval for the CGI to sleep before returning its response to the client.
expires	Optional. Sets an Expires HTTP response header to a date calculated by adding the value of the expires attribute to the current time. The value of this attribute should be a positive or negative integer in seconds.
absolute	Optional. For future extensions.

B.3 IRCGI Document Type Definition

The following DTD succintly declares the IRCGI API markup elements, their attributes, and the legal values for those attributes if applicable.

<!ENTITY % ir-checks "if-header | if-method | if-parameter | if-upload | if-all-params" >

<!ELEMENT ircgi
  (params | comment | %ir-checks; | next)* >

<!ELEMENT comment (#PCDATA) > 

<!ELEMENT if-parameter
  (comment | %ir-checks; | next)*  >
<!ATTLIST  if-parameter
  name CDATA #REQUIRED
  value CDATA #IMPLIED
  starts-with  CDATA #IMPLIED
  ignore-case (true|false) "false" > 

<!ELEMENT if-all-params
  (comment | %ir-checks; | next)*  >
<!ATTLIST  if-all-params
  ref IDREF #REQUIRED> 

<!ELEMENT params
  (param+)>
<!ATTLIST params 
  id ID #REQUIRED> 

<!ELEMENT param EMPTY> 
<!ATTLIST param   
  name CDATA #REQUIRED
  value CDATA #REQUIRED>
  
<!ELEMENT if-upload
  (comment | %ir-checks;  | next)* >
<!ATTLIST if-upload 
  name CDATA  #REQUIRED
  size   CDATA #IMPLIED> 

<!ELEMENT if-header 
  (comment | %ir-checks; | next)* >
<!ATTLIST if-header
  name CDATA #REQUIRED
  value  CDATA #IMPLIED
  starts-with CDATA #IMPLIED
  ignore-case (true|false) "false" >
<!ELEMENT if-method  
  (comment | %ir-checks; | next)* >
<!ATTLIST if-method  
  type  (get|post)  "get"  > 
 
<!ELEMENT next EMPTY>
<!ATTLIST next
  code CDATA "200"
  dest CDATA #IMPLIED
  include (true|false) "false"
  isVXML (true|false) "false"
  sleep CDATA #IMPLIED
  expires CDATA #IMPLIED
  absolute CDATA #IMPLIED>

B.4 Test examples

The following examples illustrate the use of the IRCGI API elements. The examples validate the XSLT used to generate valid CGI from the test source. These tests should all pass before the XSLT is applied to the main body of tests.

Example 1 - Verifying HTTP method

If the HTTP method used is "POST", the next document is "pass.ccxml". Otherwise, the next document is "fail.ccxml". The match on method name is case-insensitive.

<?xml version="1.0"?>
<!-- Check if request method was 'POST'. -->
<ircgi>
  <if-method value="post">
    <next dest="../pass.ccxml" /> 
  </if-method>
  <next dest="../fail.ccxml" /> 
</ircgi>

Example 2 - Verifying parameter presence

If the parameter "p1" was submitted, the next document is "pass.ccxml". Otherwise, the next document is "fail.ccxml". The value of "p1" does not matter because the value attribute was specified.

<?xml version="1.0"?>
<!--
Check if parameter p1 is present.
-->
<ircgi>
  <if-parameter name="p1">
      <next dest="../pass.ccxml" /> 
  </if-parameter>
  <next dest="../fail.ccxml" /> 
</ircgi>

Example 3 - Verifying parameter values

If parameter "p1" has the value "42" and if parameter "p2" has the value "quiche", the next document is "pass.ccxml". Otherwise, the next document is "fail.ccxml".

This document includes comment elements whose content may be included in a log element in the response document to aid in debugging.

<?xml version="1.0"?>
<!-- Check if p1 ==  42 and p2 == 'quiche'. --> 
<ircgi> 
  <if-parameter name="p1" value="42">
    <comment>p1 is 42.</comment>
    <if-parameter name="p2" value= "quiche"> 
      <comment>p2 is quiche.</comment>
      <next dest="../pass.ccxml" /> 
    </if-parameter> 
    <comment> p2 is not quiche.</comment>
    <next dest="../fail.ccxml"/>
  </if-parameter>
  <comment>p1 is not 42.</comment>
  <next dest="../fail.ccxml" /> 
</ircgi>

Example 4 - Verifying header presence and value

If the "User-Agent" HTTP header is present but is empty, the next document is "fail.ccxml". If the "User-Agent" header is present and not empty, the next document is "pass.ccxml". If the "User-Agent" header is not present, the next document is "fail.ccxml".

<?xml version="1.0" ?>
<ircgi> 
  <if-header name="User-Agent"> 
    <if-headername="User-Agent" value= ""> 
      <comment>
        User-Agent header present, but empty.
      </comment>
      <next dest="../fail.ccxml" />
    </if-header>
    <comment>
      User-Agent header was supplied and not empty.
    </comment>
    <next dest="../pass.ccxml" />
  </if-header>
  <comment>
    User-Agent header was not supplied.
  </comment>
  <next dest="../fail.ccxml" />
</ircgi>

Example 5 - Setting HTTP response status code

If the parameter "p1" was submitted, the next document is "pass.ccxml". Otherwise, the HTTP response code is set to "404".

<?xml version="1.0"?>
<!-- Send 404 if p1 not present -->
<ircgi>
  <if-parameter name="p1">
    <next dest="../pass.ccxml" /> 
  </if-parameter>
  <next code="404" /> 
</ircgi>

Example 6 - Included and generated result documents

If the parameter "p1" was "include", then parameter "p2" will be checked. If parameter "p2" was "pass", then the response will be the content of the file "pass.ccxml" because the next element's include attribute is true. If parameter "p2" is not "pass", the response will be the content of the file "fail.ccxml" because the next element's include attribute is false.

If parameter "p1" was not "include", the response document will be generated by the ircgi and include a goto to "fail.ccxml" because the include attribute was false, by default. The generated document may contain a log element containing the content of the IRCGI document's comment element.

<?xml version="1.0"?>
<!-- If p1 == 'include', include 'pass.vxml' if p2 == 'pass'. -->
<ircgi>
  <if-parameter name= "p1" value="include"> 
    <if-parameter name="p2" value="pass">
      <next dest="../pass.ccxml" include= "true"/> 
    </if-parameter>
    <next dest="../fail.ccxml" include="true"/>
  </if-parameter>
  <comment>p1 is not 'include'.</comment>
  <next dest="../fail.ccxml" /> 
</ircgi>

Example 7 - Sleeping before returning a response

This example navigates to a document "fail.ccxml" after sleeping for five seconds.

<?xml version="1.0"?>
<ircgi>
  <next dest="../fail.ccxml" sleep="5" /> 
</ircgi>

Example 8 - Using starts-with

This example checks the Content-Type header for a partial match on "multipart/form-data".

The starts-with attribute is used instead of the value attribute since the boundary portion of the value cannot be controlled or predetermined. An example of a Content-Type header value when the encoding is set to "multipart/form-data" follows:

multipart/form-data; boundary=---------------------------7d39216110392

<ircgi>
  <if-header name="Content-Type">
    <if-header name="Content-Type" starts-with="multipart/form-data" 
         ignore-case="true">
      <next dest="../pass.ccxml" />
    </if-header>
    <comment>
      Content-Type header was not multipart/form-data .
    </comment>
    <next dest="../fail.ccxml" />
  </if-header>
  <next dest="../fail.ccxml" />
</ircgi>

Example 9 - Returning the server-calculated epoch

The following example includes a .js document. The .js document includes a single statement that sets a variable to the value of the special variable __EPOCH__. At runtime, the CGI detects the special variable and replaces it with the server-calculated number of seconds since 'the epoch'. This feature is useful in testing to verify the caching behavior of a VoiceXML interpreter by making multiple IRCGI requests and comparing the values of __EPOCH__. If the values differ, the document was fetched from the Web. If not, the document was retrieved from the browser's local cache.

The IRCGI follows:

<ircgi>
  <next sleep="2" dest="../epoch.js" include="true"/>
</ircgi>

The .js document follows:

var epoch = __EPOCH__;

Example 10 - Setting Expires

This example returns the document "cache_me.ccxml" along with an Expires header set to 60 seconds after the CGI is requested.

<ircgi>
  <next dest="../cache_me.ccxml" include="true" expires="60"/>
</ircgi>

Example 11 - Verifying file uploads

If the CGI parameter named "recording" is a valid file upload and its size is equal to the value of the CGI parameter 'recsize' the next document is "pass.ccxml". Otherwise, the next document is "fail.ccxml".

<?xml version="1.0"?>
<!--
Check if upload was of a specified size.
-->
<ircgi>
  <!-- 
    @name represents the upload parameter name
    @size can refer to a static numeric value or, 
      as shown here, to a CGI parameter name
  -->
  <if-upload name="recording" size="recsize">
      <next dest="../pass.ccxml" /> 
  </if-upload>
  <next dest="../fail.ccxml" /> 
</ircgi>

Example 12 - Verifying all CGI parameters

The following IRCGI expects precisely 3 CGI parameters the names and values of which are designated by the contents of the params element referenced by the if-all-params element.

<?xml version="1.0"?>
<!-- Check if submitted parameters are in the set plist1 -->
<ircgi>
  <params id="plist1">
  <param name="p1" value="42"/>
  <param name="p2.dinner.main" value="quiche"/>
  <param name="p3" value="a 1 c"/>
  </params>
  <if-all-params ref="plist1">
      <next dest="../pass.ccxml" /> 
  </if-all-params>
  <next dest="../fail.ccxml" />
</ircgi>

Example 13 - VoiceXML document generation

The following IRCGI generates a VoiceXML document because the attribute isVXML is "true".

<?xml version="1.0"?>
<!-- Generation of VoiceXML document -->
<ircgi>
      <next  isVXML="true" dest="../312.vxml" sleep="10"/> 
</ircgi>

B.5 Usage

For security purposes, transformed IRCGI documents are deployed to an isolated directory, named "cgi-bin" under the assertion directory. Other, non-IRCGI, server-side programs that may be needed are also located in the "cgi-bin" directory.

B.6 Transformation requirements

The source IRCGI documents must be transformed into files that are executable in the test environment, such JSP files. The output files must reside in the "cgi-bin" directory and must have the ".ircgi" file extension. The file extension must be ".ircgi" because this is how other test documents (.txml) will refer to them. The .txml to .vxml transformation process cannot automatically change ".ircgi" ".pl" or ".jsp" because some tests may use ECMAScript expressions to build the reference to the ".ircgi" document.

B.7 Reference XSLT documents

The following XSLT document can be used to transform an IRCGI document to JSP:

<?xml version="1.0"?>
<?xml version="1.0"?>
<!-- Copyright 1998-2010 W3C (MIT, ERCIM, Keio), All Rights Reserved. See http://www.w3.org/Consortium/Legal/. -->
<!-- Transforms an ircgi test file into a Java Server Page.-->
<!-- 
    NOTE: This JSP requires the com.oreilly.servlet package available at http://www.servlets.com/cos/
0    The source code, object code, and documentation in the com.oreilly.servlet package
    (http://www.servlets.com/cos/) is copyright and owned by Jason Hunter.
-->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>

<xsl:template match="/" >
  <xsl:apply-templates />
</xsl:template>

<xsl:template match="ircgi">
  <xsl:call-template name="header" />
  <xsl:call-template name="declarations" />
  <xsl:call-template name="determineResult" />
</xsl:template>

<!--   Official contentType is 'application/ccxml+xml'.
  Change contentType to 'text/xml' to view generated JSP in IE.

   NOTE: The "header" template content below must be on a single line so that whitespace is not
   introduced at the beginning of the resulting XML document. XML parsers will complain. 
   Line breaks are included here for readability in the documentation.
 -->
<xsl:template name="header" ><%@ page language="java" contentType="text/xml" %><%@ page import="java.io.*" %><%@ page import="java.net.*" %><%@ page import="java.util.*" %><%@ page import="com.oreilly.servlet.multipart.*" %></xsl:template>

<!--   Define a Result class to hold the destination, comments, and
  HTTP status code that will be set by 'determineResult' method.
-->
<xsl:template name="declarations"><%!
    
    // Handles server side includes so they can be parsed
    private class JSPIncluder
    {
		void readInput(HttpServletRequest request, String strIncludePath, boolean absolute) throws JspException    
		{
        	URLConnection conn;

        	// Get URL
        	StringBuffer strUrl;
			String strUri;

			if(!absolute){
				strUrl = request.getRequestURL();
        		strUri = strUrl.toString();
        		int nFindSlash = strUri.lastIndexOf("/");
        		if (nFindSlash != -1)
        		{
            		strUri = strUri.substring(0, nFindSlash + 1);              
        		}
        		strUri += strIncludePath;
			 }else{
				strUri = strIncludePath;
			 }
        	// Open connection
        	try
        	{
            	conn = (new URL(strUri)).openConnection();
            	conn.setDoInput(true);
            	conn.setDoOutput(false);
            	conn.connect();
        	}
            catch (Exception e)
            {
                throw new JspException(e.toString());
            }

            // Read in contents
            try
            {
                BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream()));
                StringBuffer buff = new StringBuffer();
                char[] chars = new char[2048];
                int nLen;

                while ((nLen = in.read(chars, 0, chars.length)) >= 0)
                {
                    buff.append(chars, 0, nLen);
                }
                m_strBuffer = buff.toString();
                in.close();
            }
            catch (Exception e)
            {
                throw new JspException(e.toString());
            }
        }

        boolean replace(String strFind, String strReplace)
        {
            boolean bFound = false;
            if (m_strBuffer != null && m_strBuffer.length() > 0)
            {
                int a = 0;
                int b = 0;
                while (true)
                {
                    a = m_strBuffer.indexOf(strFind, b);
                    if (a != -1)
                    {
                        m_strBuffer = m_strBuffer.substring(0, a) + strReplace + m_strBuffer.substring(a + strFind.length());
                        b = a + strReplace.length();
                        bFound = true;
                    }
                    else
                    {
                        break;
                    }
                }
            }
            return bFound;
        }
        
        void doOutput(PageContext context) throws JspException
        {
            JspWriter out = context.getOut();
            try
            {
                out.print(m_strBuffer.toString());
            }
            catch (Exception e)
            {
                throw new JspException(e.toString());
            }   
        }
        private String m_strBuffer;
    }
    
    // Handles multipart/form-data 
    private class MultiPartHandler 
    {
        HttpServletRequest request;
        
        public MultiPartHandler(HttpServletRequest req)
        {
            request = req;
        }
        
        public boolean find(String strFind, int nOfSize) throws JspException 
        {            
            MultipartParser parser;
            Part part;
            String strName;
            if((request.getContentType() != null)&&(request.getContentType().startsWith("multipart/form-data")))
            {
                try
                {
                    parser = new MultipartParser(request, request.getContentLength());
                    while ((part = parser.readNextPart()) != null)
                    {
                        strName = part.getName();
                        if(strName.equals(strFind))
                        {
                            if (nOfSize == -1)
                            {
                                return true;
                            }
                            else
                            {
                                if (part.isFile())
                                {
                                    InputStream stream = ((FilePart)part).getInputStream();
                                    if (getSizeOfStream(stream) == nOfSize)
                                    {
                                        return true;
                                    }
                                }
                            }
                        }
                    }
                }
                catch (Exception e)
                {
                    throw new JspException(e.toString());
                }
            }
            
            return false;        
         }
         
         private long getSizeOfStream(InputStream stream)
         {
            if (null == stream) return 0;
            
            int nRead = 0;
            int nSize = 0;
            byte[] temp = new byte[1024];
            try 
            {
                while ((nRead = stream.read(temp)) != -1)
                {
                    nSize += nRead;
                }  
            }
            catch (IOException e) {}
            
            return nSize;         
         }
     }
    
  private class Result {
    String dest;
    long sleep = 0;
    boolean expiresHeaderSet = false;
    long expires = 0;
    boolean include = false;
    boolean isVXML = false;
    StringBuffer comments = new StringBuffer();
    int statusCode = 200;
	boolean absolute = false;
  }
  private final String NL = System.getProperty("line.separator");
  private void determineResult(HttpServletRequest request, Result result, MultiPartHandler multipart) throws JspException
  {
    <xsl:apply-templates />
  }
%></xsl:template>

<!--  Create Result object and call 'determineResult' to set its fields.
  Return CCXML document only if HTTP response status code is 200.
  Otherwise, return just the status code.
-->
<xsl:template name="determineResult" ><%
    Result myResult = new Result();
    MultiPartHandler myMultiPart = new MultiPartHandler(request);
    determineResult(request, myResult, myMultiPart);
    response.setStatus(myResult.statusCode);
    
    if (myResult.sleep > 0)
    {
        try
        {
            Thread.sleep(myResult.sleep * 1000);
        }
        catch (InterruptedException e)
        {
            throw new JspException(e.toString());
        }
    }
    
    if (myResult.expiresHeaderSet)
    {
        Date now = new Date();
        long nMillis = now.getTime();
        response.setDateHeader("Expires", nMillis + myResult.expires*1000);
    }
    
    if (myResult.include) 
    {
        Date now = new Date();
        long nMillis = now.getTime();
        String strEpoch = String.valueOf(nMillis);
        JSPIncluder includer = new JSPIncluder();
        includer.readInput(request, myResult.dest, myResult.absolute);
        includer.replace("__EPOCH__", strEpoch);
        includer.doOutput(pageContext);
    }
    else if (myResult.isVXML) 
    	{%><xsl:call-template name="vxml" /><%}
    else
    	{%><xsl:call-template name="ccxml" /><%}%> 
   
</xsl:template>

<xsl:template match="if-parameter" >
  if (<xsl:call-template name="genIfExpr">
        <xsl:with-param name="type" select="'Parameter'" />
      </xsl:call-template>) {
    <xsl:apply-templates />
  }
</xsl:template>

<xsl:template match="if-header" >
  if (<xsl:call-template name="genIfExpr">
        <xsl:with-param name="type" select="'Header'" />
      </xsl:call-template>) {
    <xsl:apply-templates />
  }
</xsl:template>

<xsl:template match="if-all-params" >
  if (<xsl:for-each select="/ircgi/params[@id=current()/@ref]/param">
        <xsl:call-template name="genIfExpr">
          <xsl:with-param name="type" select="'Parameter'" />
        </xsl:call-template>
        <xsl:if test="position() != last()">&&</xsl:if>
      </xsl:for-each>) {
    <xsl:apply-templates />
  }
</xsl:template>

<xsl:template match="if-upload" >
  int nSize = -1;
  <xsl:if test="@size">
    if (null != request.getParameter("<xsl:value-of select='@size'/>"))
    {
      try {
        nSize = Integer.parseInt(request.getParameter("<xsl:value-of select='@size'/>"));
      }
      catch (NumberFormatException e) { }
    }
    else
    {
      try {
        nSize = Integer.parseInt("<xsl:value-of select='@size'/>");
      }
      catch (NumberFormatException e) { }
    }
  </xsl:if>  
  if (multipart.find("<xsl:value-of select="@name"/>", nSize))
  {
    <xsl:apply-templates />
  } 
</xsl:template>

<!--  Generate an expression that determines when the condition of an if-parameter / if-header
  element is true.  The 'type' parameter determines the
  HttpServletRequest method to use to get the value to be checked.
-->
<xsl:template name="genIfExpr" >
  <xsl:param name="type" />
  <xsl:param name="size" />
  <xsl:variable name="method">
    <xsl:choose>
      <xsl:when test="@ignore-case = 'true'" >equalsIgnoreCase</xsl:when>
      <xsl:otherwise>equals</xsl:otherwise>
    </xsl:choose>
  </xsl:variable>
  <xsl:choose>
    <xsl:when test="@value">
      request.get<xsl:value-of select="$type"/>
        ("<xsl:value-of select="@name"/>") != null &&
      request.get<xsl:value-of select="$type"/>
        ("<xsl:value-of select="@name"/>").<xsl:value-of select="$method"/>
        ("<xsl:value-of select="@value" />")
    </xsl:when>
    <xsl:when test="@starts-with">
       request.get<xsl:value-of select="$type"/>
        ("<xsl:value-of select="@name"/>") != null &&
       request.get<xsl:value-of select="$type"/>
        ("<xsl:value-of select="@name"/>").startsWith("<xsl:value-of select="@starts-with"/>")
    </xsl:when>     
    <xsl:otherwise>
      request.get<xsl:value-of select="$type"/>("<xsl:value-of select="@name"/>") != null 
        || multipart.find("<xsl:value-of select="@name"/>", -1)
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

<xsl:template match="if-method" >
  if (request.getMethod().equalsIgnoreCase("<xsl:value-of select="@type" />")) {
    <xsl:apply-templates />
  }
</xsl:template>

<!--  Disarm double quotes and newline characters from comments, then
  add to result's comment buffer for use later in 'log' element.
-->
<xsl:template match="comment" >
  result.comments.append
    ("<xsl:value-of select="translate(., '"
', '   ')" />".trim());
  result.comments.append(NL);
</xsl:template>

<xsl:template match="next" >
  <xsl:if test="@code" >
    result.statusCode = <xsl:value-of select="@code" />;
  </xsl:if>
  <xsl:if test="@dest" >
      result.dest = "<xsl:value-of select="@dest" />";
  </xsl:if>
  <xsl:if test="@param">
	result.dest = request.getParameter("<xsl:value-of select="@param"/>");
  </xsl:if>
  <xsl:if test="@include = 'true'">
    result.include = true;
  </xsl:if>  
  <xsl:if test="@isVXML = 'true'">
    result.isVXML = true;
  </xsl:if>  
  <xsl:if test="@sleep">
      result.sleep = <xsl:value-of select="@sleep" />;
  </xsl:if>  
  <xsl:if test="@expires">
      result.expiresHeaderSet = true;
      result.expires = <xsl:value-of select="@expires" />;
  </xsl:if>
  <xsl:if test="@absolute">
	result.absolute = <xsl:value-of select="@absolute"/>;
  </xsl:if>
    return;
</xsl:template>

<!--  Generate CCXML document that does a 'goto' to the document
  indicated in myResult.  If comment buffer is not empty, include
  a 'log' element to aid in debugging.
-->

<xsl:template name="ccxml" ><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">
  <eventprocessor>
    <transition event="ccxml.loaded">
      <% String comments = myResult.comments.toString();
        if (comments.length()>0) {%>
        <log>]]>
        <xsl:text disable-output-escaping="yes">
          <![CDATA[<%= comments %>]]>
        </xsl:text><![CDATA[
        </log><%}%>
        <fetch next="'<%= myResult.dest %>'"/>
    </transition>
  <transition event="fetch.done">
    <goto fetchid="event$.fetchid"/>
  </transition>
</eventprocessor>
</ccxml> ]]>
</xsl:template>

<!--  Generate VoiceXML document that does a 'goto' to the document
  indicated in myResult.  If comment buffer is not empty, include
  a 'log' element to aid in debugging.
-->

<xsl:template name="vxml" ><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1" xmlns="http://www.w3.org/2001/vxml">
  <form>
    <block><% String comments = myResult.comments.toString();
   if (comments.length()>0) {%>
      <log>]]>
        <xsl:text disable-output-escaping="yes">
          <![CDATA[<%= comments %>]]>
        </xsl:text><![CDATA[
      </log><%}%>
      <goto next="<%= myResult.dest %>"/>
    </block>
  </form>
</vxml> ]]>
</xsl:template>

</xsl:stylesheet>

B.8 Test developer requirements

The directory convention requires test developers to ensure that paths from and to other test documents follow the convention.

The following example contains a reference to an IRCGI document from a VoiceXML document:

<goto next="cgi-bin/ua.ircgi" />

The following example contains a reference to a CCXML document from an IRCGI document:

<next dest="../pass.ccxml"/>

B.9 Web server administrator requirements

Given the directory convention, Web server administrators must do the following:

• Allow CGI execution within the "cgi-bin" directory below each assertion directory.
• Associate the ".ircgi" suffix with the preferred server-side script engine.

The following example configures Tomcat to run transformed files with a .ircgi extension as a JSP:

<servlet-mapping>
  <servlet-name>jsp</servlet-name>
  <url-pattern>*.ircgi</url-pattern>
</servlet-mapping>

Appendix C - Downloading tests

The "ccxml10-ir-20110412.zip" archive contains several resources. This report is composed of a number of Jumbo tests to verify many assertions in a single testing document (see Appendix A.6 for details on Jumbo tests). The Jumbo tests are organised into folders where the folder name corresponds to the test ID. In addition the archive includes the following:

• C.1 The Manifest
• C.2 The Assertion Manifest
• C.3 The Report Submission Template
• C.4 The Stylesheet

C.1 The Manifest

The "manifest.xml" is a file containing the complete information about the Jumbo tests that comprise the CCXML Implementation Report. The structure of the Manifest presents a root element called <tests> ; this is the container of all the Jumbo tests. Every Jumbo test is represented by a <test> element containing other elements, such as <assert> to declare test assertions to be tested by the Jumbo test, <instruction> to give instructions to the testers, <start> to declare the initial .txml document, and <dep> to declare other dependent documents. <assert> can contain CDATA that represents the description of the test assertion, but it is currently empty (that information is already present in the Assertion Manifest for each assertion, see below). The <start> element references the main test file and may optionally be followed by one or more <dep> elements that identifies other resources useful to complete the test case. Here's the DTD for the Manifest:

<!ELEMENT assert (#PCDATA)>
<!ATTLIST assert
    id CDATA #REQUIRED
    spec CDATA #IMPLIED
    optional (true | false) #IMPLIED
    manual (true | false) #IMPLIED
    teststartuptype (alerting | connected | noconnection) #IMPLIED
>
<!ELEMENT dep EMPTY>
<!ATTLIST dep
    uri CDATA #REQUIRED
    type CDATA #IMPLIED
>
<!ELEMENT start EMPTY>
<!ATTLIST start
    uri CDATA #REQUIRED
    type CDATA #IMPLIED
>

<!ELEMENT instruction (#PCDATA)>

<!ELEMENT test ((assert*, instruction*)+, start, dep*)>
<!ATTLIST test
    id CDATA #REQUIRED
    spec CDATA #REQUIRED
    manual (true | false) "false"
    teststartuptype (alerting | connected | noconnection) #REQUIRED
>
<!ELEMENT tests (test+)>

Jumbo test typology is defined by several attributes on the <test> element. These attributes allow for a more complete identification of the nature of the current assertion and an idea of related tests structure.

• id : Jumbo Test Identifier which corresponds to the test folder name;
• spec: reference to a section of the CCXML 1.0 Specification;
• teststartuptype: information about the starting transition. In particular, it can assume one of the following possible values: “alerting”, “connected”, “noconnection”, see Appendix A.1.2 for definition;
• manual: this is present only if the test must be manually executed;

<start> and <dep> elements are characterized by the following attributes:

• uri: relative URI that links to the referenced file;
• type: the media type of the referenced file;

For instance here’s a fragment of the manifest.xml document:

<?xml version="1.0"?>
<tests>
[…]
  <test id="10_2_2_A" teststartuptype="alerting" spec="10.2.2">
    <assert id="283"/>
    <assert id="285"/>
    <start uri="10_2_2_A/10_2_2_A.txml"/>
    <dep uri="10_2_2_A/test.vxml"/>
  </test>
[…]
</tests>

C.2 The Assertion Manifest

The "manifest.assert.xml" is a file containing the complete information about test assertions included in the Jumbo tests. The structure of the Assertion Manifest presents a root element called <tests> ; this is the container of all the Test Assertions. Every Test Assertion is represented by a <test> element containing a single <assert> element to give specific information on the Test Assertion. <assert> must contain CDATA that represents the description of the test assertion. Here's the DTD for the Assertion Manifest:

<!ELEMENT assert (#PCDATA)>
<!ATTLIST assert
    id CDATA #REQUIRED
    spec CDATA #REQUIRED
    optional (true | false) "false"
    manual (true | false) "false"
    teststartuptype (alerting | connected | noconnection) #IMPLIED
>
<!ELEMENT test (assert)>
<!ELEMENT tests (test+)>

The Test Assertion is defined by several attributes on the <assertion> element. These attributes allow for a more complete identification of the nature of the current test assertion.

• id : test assertion identifier;
• spec: reference a section belonging to the CCXML 1.0 Specification where the test assertion is declared;
• teststartuptype: information about the starting transition (no longer present). In particular it can assume one of the following possible values: “alerting”, “connected”, “noconnection”;
• manual: this is present only if the test must be manually executed;
• optional: this declares if the assertion is mandatory or optional;

For instance here’s a fragment of the manifest.xml document:

<?xml version="1.0"?>
<tests>
[…]
  <test>
    <assert id="606" optional="false" manual="false" spec="6.2.1">
      <![CDATA[The <ccxml> can designate the CCXML namespace. 
      This can be achieved by declaring an xmlns attribute or an attribute 
      with an "xmlns" prefix.]]>
    </assert>
  </test>
[…]
</tests>

C.3 The Report Submission Template

The "ccxml10-ir-results-template.xml" report template has to be filled by the company following the rules described in Section 3. An excerpt of the Template is shown below:

<system-report name="YOUR-SYSTEM-NAME-HERE">
<testimonial> YOUR-WELL-FORMED-TESTIMOMIAL-CONTENT-HERE</testimonial>
<assert id="Id1" res="pass|fail|not-impl">OPTIONAL-NOTES-HERE</assert>
        [...]
<assert id="Idn" res="pass|fail|not-impl">OPTIONAL-NOTES-HERE</assert>
</system-report>

C.4 The Stylesheet

A specific stylesheet transforms the meta markup language used to write the tests into valid CCXML 1.0 documents (the stylesheet is described in Appendix A.5). The stylesheet tranformation for dynamic CCXML/VoiceXML documents is described in Appendix B.7.

Appendix D - Acknowledgements

The CCXML 1.0 Implementation Report includes over 1200 assertions with 565 actually implemented in this Report. The Voice Browser Working Group would like to acknowledge the contributions of several individuals for authoring and reviewing assertions and for working on the test suite development. Without their help this activity would have been impossible:

• Patrizio Bergallo, Loquendo (until January 2008)
• Emily Candell Bateman, Comverse
• Chris Davis, Interact Incorporated
• Brandon Emerson, Intervoice
• Srikant Govardhan, Nortel
• Petr Kuba, OptimSys
• Chris Maxwell, Voxeo
• Rachel Muller, Aspect
• Mark Scott, Genesys
• Sandip Shah, Alcatel-Lucent
• Scott Slote, Nortel

The Voice Browser Working Group would also like to acknowledge the following contributors:

• Vince Busam, Genesys
• Brian Frasca, Tellme
• Jeff Haynie, Vocalocity
• Alex Lee, Genesys
• Scott McGlashan, HP
• Brian Muschett, IBM
• Matt Oshry, Tellme
• Ken Rehor, CISCO
• Dave Renshaw, IBM
• Andy Thomas, InterVoice

Appendix E - Changes from the previous version

This Implementation Report was modified based on the comments sent to the Voice Browser public list as follows. Each ISSUE is linked to the modified test, where a comment is present to clarify all the assertions changed.

12 April 2011

• Updated following tests:
  • ISSUE-723: added an empty connection.merged transition;
  • ISSUE-724: added documents to check inconsistency of prepareddialogid with other attributes: TA_1186_parameters.ccxml, TA_340_349_namelist.ccxml, TA_342_src.ccxml, TA_347_type.ccxml, TA_366_maxage.ccxml, TA_368_maxstale.ccxml, TA_370_enctype.ccxml, TA_373_method.ccxml;
  • ISSUE-725: added exit on error.fetch and fetch.done, consequently added an empty ccxml.exit transition in parent session;
  • ISSUE-726: version 2.0 replaced by version 2.1;
  • ISSUE-727: added declaration of rr in jumbo_test_ccxml_sample.xslt;
  • ISSUE-728: added block element;
  • ISSUE-730: TA 371: Assigned method to POST on dialogstart;
  • ISSUE-731: TA 774, 775: removed quotes in maxage values;
  • ISSUE-732: TA 773: restructured test;
  • ISSUE-733: added reason on error.494 event;
  • ISSUE-735: added parameters and syntactic changes;
  • ISSUE-736: added connectionid on dialogstart;
  • ISSUE-737: added variables i and result declarations;
  • ISSUE-739: TA 1286: added an empty connection.disconnected transition;
  • ISSUE-740: TA 425: managed the prepare_new event in dialog.exit and conference.unjoined events;
  • ISSUE-750: changed grammar type to srgs+xml and fixed grammar content;
  • ISSUE-771: TA 427: dtmfclamp set to false added in join on ConnectionID and ConferenceID to allow DTMF termination;
  • NO ISSUE: TA 615: replaced errorNoneDeclared_615_1.ccxml with errorFetchMeta615_1.ccxml;
  • NO ISSUE: fixed syntax error;
  • NO ISSUE: revised implementation;
  • NO ISSUE: TA 1292, 1295: added comment about double PASS in logs is mandatory to consider TAs passed;
  • NO ISSUE: TA 72: revised implementation;
  • NO ISSUE: added 2s delay to listen exit tone.

15 July 2010

• Updated following tests:
  • 714.
• Rejected assertions:
  • 287, ISSUE-672;
  • 555, ISSUE-689;
  • 852, ISSUE-690.
• Updated following tests:
  • ISSUE-670: reason added for sending ccxml.kill and ccxml.unconditional events;
  • ISSUE-677: TA 798 changed scope chain test;
  • ISSUE-680: TA 699, TA 1014 missed '+' in ECMA expression;
  • ISSUE-683: TA 757,758,759 added declaration of var2 and var3;
  • ISSUE-684: TA 773 quotes for timeout value in script element;
  • ISSUE-685: vxml version replaced by 2.1;
  • ISSUE-686: TA 1033 replaced 'ccxml' by 'createsession' in session.ioprocessors associate array index;
  • ISSUE-691#1: minor typo;
  • ISSUE-691#2, ISSUE-712: added block element container for prompt;
  • ISSUE-693: TA 772 fixed .ccxml extension instead of .txml;
  • ISSUE-694#1: TA 858 added quotes in ASSERTION_NMBR_858_DESTROYING_CONFERENCES;
  • ISSUE-694#2: TA 797 added quotes in user.A979_finish;
  • ISSUE-695: TA 858 fixed spelling error.conference.unjoined;
  • ISSUE-696#1: TA 1033 fixed regular expression;
  • ISSUE-696#2: TA 1033 conference.unjoined added;
  • ISSUE-697#1: quotes for maxage and maxstale values;
  • ISSUE-697#3: conference.unjoined added;
  • ISSUE-698: TA 859 conference.unjoined added;
  • ISSUE-701: TA 889 conference.unjoined added;
  • ISSUE-702: quotes for entertone and exittone values;
  • ISSUE-703#1: fixed condition in if element;
  • ISSUE-703#2: fixed condition in if element;
  • ISSUE-703#3: changed conditions on input and outputs;
  • ISSUE-704: conference.unjoined added;
  • ISSUE-705#2: fixed paramcc3 declaration;
  • ISSUE-705#3: conference unjoined added and existent conference.unjoined conditioned on connectionid added on TA 404 (so that conference unjoined on dialogid will be caught by generic conference.unjoined transition) added;
  • ISSUE-705#4: quotes for maxage and maxstale values;
  • ISSUE-706#3: conference.unjoined added;
  • ISSUE-709: missing 'result' variable declaration;
  • ISSUE-711: TA 420 extended condition to include '0ms';
  • ISSUE-712: added block element container for prompt;
  • ISSUE-713: TA 739 removed assignment to 'bool_738_ccxml_7';
  • ISSUE-715: TA 147 missing declaration of 'hints' variable.