Re: April CCXML: 3 problems w/7_5.txml - [cc] ISSUE-706

Chris,

We are in the process to address all ISSUES related to IR. The goal is to re-publish the CCXML-IR in a short term.
Please explicitly confirm that you accept the proposed resolution or after one week we will consider implicitly accepted the resolution. If you need clarification, please ask them very soon.

Paolo Baggia
Author of CCXML-IR Plan

ISSUE-706:

Here are the resolutions for your four issues:

1. The Spec will be fixed to define immediate attribute to be of type ECMAScript Boolean expression, like other similar attributes, so that, the default value and description values will remain the same. With this resolution the test don't need to be changed.

2. Rejected, see below the explanation of who implemented it. The group judged it correct.

3. Right, the event will be added.

----
TA 312 says: "A <dialogprepare> element does not block the processing of further events by the CCXML session. "

So in test 7.5.txml for the TA 312 we have the following statement:

<dialogprepare src="'cgi-bin/' + cgi_1" dialogid="DialogID" connectionid="ConnectionID"/> <send target="session.id" targettype="'ccxml'" name="'ccxml.myEvent'" delay="'5s'" sendid="myCcxmlSendId"/>

We prepare a dialog whose preparation duration is 10 seconds and we send a ccxml.myEvent with a delay of 5 seconds => the ccxml.myEvent event must be sent to the CCXML application BEFORE the notification of dialog.prepared, in this way we demonstrate that the processing of custom event has not been blocked even if a dialog preparation is currently working:

When the ccxml.myEvent has been received the CCXML application checks if the dialog preparation has not been received yet (so bPreparedReceived is "false"): this condition states that the test has been successfully PASSED because the dialog preparation did not block the processing of ccxml.myEvent. So the condition is " if cond="!bPreparedReceived">" (same thing as bPreparedReceived == false), see below:

<transition event="ccxml.myEvent" state="ASSERTION_NMBR_312">
		<conf:comment expr=" 'Current state : ' + current_state + ' , Event: ' + event$.name"/>
		<assign name="bMyEventReceived" expr="true"/>
		<if cond="!bPreparedReceived">
			<script>assertions[assert_index].P_F = s_PASS;</script> [...]

=================================
This thread is tracked as ISSUE-706. 

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800 

On May 18, 2010, at 3:36 PM, Chris Davis wrote:

> Hello www-voice,
> 
> We ran into 3 problems with 7_5.txml of the CCXML test cases:
> 
> 1) <dialogterminate> needs immediate="'false'" (string) not "false" (boolean)
> because 7.2.3.2 says of the immediate attribute that it is "An ECMAScript expression which returns a character string"
> 
> If we can, I'd recommend changing the Recommendation to read "An ECMAScript expression which returns a boolean"
> and leave the test case unchanged. As it is, we need to keep the tests consistent with the Recommendation. This inconsistency
> is duplicated across many test cases.
> 
> 2)  <if cond="!bPreparedReceived"> needs to be <if cond="bPreparedReceived">. All the logic is screwed up
> the way it is currently coded
> 
> 3) needs a do-nothing conference.unjoined transition, as the test writer did not account for the conference.unjoined
> that is associated with a terminating dialog
> 
> -- 
> Chris Davis
> Interact Incorporated R&D
> 512-502-9969x117

Received on Friday, 2 July 2010 08:26:49 UTC