CCXML 1.0: Candidate Recommendation Disposition of Comments
- This version:
- Thu Mar 31 09:01:05 EDT 2011
- Editor:
- RJ Auburn, Voxeo
This document details the responses made by the Voice Browser Working Group to issues raised during the Candidate Recommendation period (beginning 1 April 2010 and ending 28 May 2010). www-voice-request@w3.org( archive) mailing list.
This document of the W3C's Voice Browser Working Group describes the disposition of comments as of 13 January 2011 on the Candidate Recommendation Voice Browser Call Control XML (CCXML) Version 1.0.It may be updated, replaced or rendered obsolete by other W3C documents at any time.
For background on this work, please see the Voice Browser Activity Statement.
Legend:
| ACCEPTED | Comment was accepted |
| REJECTED | Comment was rejected |
| TEXTSUPERSEDED | Text that was commented on had already been changed. |
| CLARIFICATION | Comment only required a clarification. |
| DROPPED | Feature or text in question was removed from the spec. |
| REASSIGNEDID | Issue number was changed to a new ID |
| MIX | Parts of the comments were accepted and other parts were rejected. |
Results:
| ID | Title | Date Opened | Last Updated | Disposition | Acceptance | Related Issues |
|---|---|---|---|---|---|---|
| ISSUE-668 | PUBLIC - CR - April 2010 CCXML's DTD is broken | 2010-04-08 | 2011-01-12 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-669 | PUBLIC - CR - attribute type error in 1 April 2010 CCXML | 2010-04-08 | 2011-01-12 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-670 | PUBLIC - CR - CCXML Implementation Report: asserts 714 and 715 | 2010-04-08 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-671 | PUBLIC - CR - Recommended addition to the April 2010 CCXML DTD | 2010-04-13 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-672 | PUBLIC - CR - April 2010 CCXML Connection class dialogid? | 2010-04-13 | 2010-08-18 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-673 | PUBLIC - CR - April 2010 CCXML test case problem | 2010-04-13 | 2010-06-09 | REJECTED | EXPLICIT | NONE |
| ISSUE-674 | PUBLIC - CR - CCXML specification: Application variables | 2010-04-13 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-675 | PUBLIC - CR - CCXML specification: typo in Appendix K.3 | 2010-04-13 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-676 | PUBLIC - CR - April CCXML: problem in test document 8_2_1_A.txml | 2010-04-25 | 2010-06-09 | REJECTED | EXPLICIT | NONE |
| ISSUE-677 | PUBLIC - CR - April CCXML: test case conflicts with ECMA rules | 2010-04-25 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-678 | PUBLIC - CR - April CCXML: bad function in test document 6_1.txml | 2010-04-25 | 2010-04-25 | REJECTED | EXPLICIT | NONE |
| ISSUE-679 | PUBLIC - CR - April CCXML: bad assignments in test document 6_1 | 2010-04-25 | 2010-04-25 | REJECTED | EXPLICIT | NONE |
| ISSUE-680 | PUBLIC - CR - April CCXML: problem found in test document 6_1.txml | 2010-04-25 | 2010-07-08 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-681 | PUBLIC - CR - April CCXML: "Class" definition | 2010-04-25 | 2011-01-12 | DROPPED | EXPLICIT | NONE |
| ISSUE-682 | PUBLIC - CR - April CCXML: Dialog properties inconsistency | 2010-04-25 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-683 | PUBLIC - CR - CCXML Implementation Report: couple of problems in scripts - #1 Assignment without declaration | 2010-04-25 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-684 | PUBLIC - CR - CCXML Implementation Report: couple of problems in scripts - #2 Invalid value of the <script> timeout parameter | 2010-04-25 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-685 | PUBLIC - CR - CCXML Implementation Report: couple of problems in scripts - #3 Incorrect VXML script version | 2010-04-25 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-686 | PUBLIC - CR - CCXML Implementation Report: couple of problems in scripts - #4 Wrong I/O processor type | 2010-04-25 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-687 | PUBLIC - CR - CCXML Implementation Report: couple of problems in scripts - #5 Relative target URI in <send> using basichttp | 2010-04-25 | 2010-07-04 | REJECTED | EXPLICIT | NONE |
| ISSUE-688 | PUBLIC - CR - CCXML Implementation Report: couple of problems in scripts - #6 Typo in xslt | 2010-04-25 | 2010-04-25 | REJECTED | IMPLICIT | NONE |
| ISSUE-689 | PUBLIC - CR - April CCXML: test id 555 incorrect? | 2010-05-13 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-690 | PUBLIC - CR - April CCXML: test case 882 error? [should be 852] | 2010-05-13 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-692 | PUBLIC - CR - Dialog and Connection semantic error handling | 2010-05-13 | 2010-09-05 | CLARIFICATION | EXPLICIT | NONE |
| ISSUE-693 | PUBLIC - CR - April CCXML: minor issue in 8_2_3_A.txml | 2010-05-13 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-694 | PUBLIC - CR - April CCXML: Two breaks in 10_5_8_A.txml | 2010-05-13 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-695 | PUBLIC - CR - April CCXML: break in 10_5_8_A_978.txml | 2010-05-13 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-696 | PUBLIC - CR - April CCXML: 2 bugs in 8_3_B.txml | 2010-05-13 | 2010-07-07 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-697 | PUBLIC - CR - April CCXML: 3 bugs in 7_1.txml | 2010-05-13 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-698 | PUBLIC - CR - April CCXML: no unjoined for 859 in 10_5_8_A.txml | 2010-05-26 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-701 | PUBLIC - CR - April CCXML: error in 7_6_2.txml | 2010-05-26 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-702 | PUBLIC - CR - April CCXML: 3 problems with manual tests (10_5_7_A_*.txml) | 2010-05-26 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-703 | PUBLIC - CR - April CCXML: 3 errors in 10_5_7_A.txml | 2010-05-26 | 2010-07-08 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-704 | PUBLIC - CR - April CCXML: problem w/7_4.txml | 2010-05-26 | 2010-07-07 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-705 | PUBLIC - CR - April CCXML: 4 issues w/7_2.txml | 2010-05-26 | 2010-08-18 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-706 | PUBLIC - CR - April CCXML: 3 problems w/7_5.txml | 2010-05-26 | 2010-08-18 | MIX | EXPLICIT | NONE |
| ISSUE-707 | PUBLIC - CR - April CCXML: attribute 'id' of the error.notallowed event | 2010-06-03 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-708 | PUBLIC - CR - April CCXML: wrong assumption in 7_1, assertion 463, 467 | 2010-06-03 | 2010-07-04 | REJECTED | EXPLICIT | NONE |
| ISSUE-709 | PUBLIC - CR - April CCXML: variable not declared in 6_3 | 2010-06-03 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-710 | PUBLIC - CR - April CCXML, 7_1: attribute enctype used with the value of the method "post" in <dialogprepare> | 2010-06-03 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-711 | PUBLIC - CR - April CCXML 7_3: maxtime unlimited value in dialog.transfer | 2010-06-03 | 2010-08-18 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-712 | PUBLIC - CR - April CCXML: invalid script 7_4.vxml | 2010-06-03 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-713 | PUBLIC - CR - April CCXML 8_2_1_B: referencing undeclared variable | 2010-06-03 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-714 | PUBLIC - CR - April CCXML: format of the name attribute in <send> | 2010-06-03 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-715 | PUBLIC - CR - April CCXML 10_5_8: undeclared variable | 2010-06-03 | 2010-07-04 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-717 | PUBLIC - CR - April CCXML 7_3: required property reason in dialog.terminatetransfer | 2010-06-03 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-718 | PUBLIC - CR - April CCXML: <fetch> clarification | 2010-06-03 | 2010-09-16 | CLARIFICATION | EXPLICIT | NONE |
| ISSUE-719 | PUBLIC - CR - April CCXML 9_2_3_B: handling of invalid event name in <send> | 2010-06-03 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-723 | PUBLIC - CR - April CCXML: Number of connection.merged events | 2010-07-29 | 2010-09-15 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-724 | PUBLIC - CR - April CCXML, 7_2: combination of attributes in <dialogstart> | 2010-07-29 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-725 | PUBLIC - CR - July CCXML Implementation Report: script child_9.ccxml in 6_1not terminating | 2010-07-29 | 2010-09-01 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-726 | PUBLIC - CR - July CCXML Implementation Report: incorrect script version in 7_2 | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-727 | PUBLIC - CR - July CCXML Implementation Report: missing 'var' in jumbo_test-ccxml-sample.xslt | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-728 | PUBLIC - CR - July CCXML Implementation Report: invalid script 7_1_2.vxml | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-729 | PUBLIC - CR - July CCXML Implementation Report: 'dialog.user.test' missing required attributes in 7_2 | 2010-07-29 | 2010-10-18 | REJECTED | EXPLICIT | NONE |
| ISSUE-730 | PUBLIC - CR - July CCXML Implementation Report: 7_2: attribute enctype used with the value of the method "get" in <dialogstart> | 2010-07-29 | 2010-08-25 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-731 | PUBLIC - CR July CCXML Implementation Report: 8_2_2: invalid maxage value in <script> | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-732 | PUBLIC - CR - July CCXML Implementation Report: 8_2_3: how to handle error in loading static <script> | 2010-07-29 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-733 | PUBLIC - CR - July CCXML Implementation Report: 9_1_B: 'error.494' event missing required attribute 'reason' | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-734 | PUBLIC - CR - July CCXML Implementation Report: 9_2_3_B: improper error event used in <send> | 2010-07-29 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-735 | PUBLIC - CR - July CCXML Implementation Report: 10_5_7 and 10_5_8: invalid scripts with <join> | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-736 | PUBLIC - CR - July CCXML Implementation Report: 10_5_8: starting a dialog that is not joined to a connection or a conference | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-737 | PUBLIC - CR - July CCXML Implementation Report: missing var in L_A.txml | 2010-07-29 | 2010-09-14 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-738 | PUBLIC - CR - July CCXML Implementation Report: L_A: eventsource in <send> | 2010-07-29 | 2010-10-18 | CLARIFICATION | EXPLICIT | NONE |
| ISSUE-739 | PUBLIC - CR - July CCXML Implementation Report: 10_2_3: missing transition for connection.disconnected - should be 10_2_4 | 2010-07-29 | 2010-08-25 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-740 | PUBLIC - CR - July CCXML Implementation Report: 7_3: unhandled conference.unjoined | 2010-07-29 | 2010-08-19 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-743 | PUBLIC - CR - CCXML: VoiceXML dialog.transfer.complete's result type incorrect | 2010-08-26 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-744 | PUBLIC - CR - CCXML: dialog.transfer example incorrect? | 2010-08-26 | 2011-01-12 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-745 | PUBLIC - CR - July CCXML Implementation Report: 10_5_7: improper error event used in <join> | 2010-08-26 | 2010-08-29 | REJECTED | EXPLICIT | NONE |
| ISSUE-750 | PUBLIC - CCXML: problem with IR 8_3_B/dialog.vxml | 2010-10-07 | 2010-10-07 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-771 | PUBLIC - CR - CCXML: question on assertion for 7_3 #427 | 2011-03-24 | 2011-03-30 | ACCEPTED | EXPLICIT | NONE |
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: April 2010 CCXML's DTD is broken
Date: April 7, 2010 11:28:40 AM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
I'm looking at the CCXML Version 1.0 Candidate Recommendation 1 April 2010
(http://www.w3.org/TR/2010/CR-ccxml-20100401/).
The DTD on the website ( http://www.w3.org/TR/2010/CR-ccxml-20100401/ccxml.dtd)
will not load/parse into some popular third party XML parsers
such as xmlsoft. On line 95 there is a stray tick (') in front of #IMPLIED and after CDATA.
This looks to many parsers as the beginning of an escape sequence and will cause them to choke.
The solution is to remove the stray tick mark.
Thanks,
Chris
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
RESULT=ACCEPTED
ACCEPTANCE=IMPLICIT,http://www.w3.org/mid/147862BE-2312-4C63-A685-2128272466E4@voxeo.com
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: attribute type error in 1 April 2010 CCXML Date: April 5, 2010 4:00:23 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, I'm looking at the CCXML Version 1.0 Candidate Recommendation 1 April 2010 (http://www.w3.org/TR/2010/CR-ccxml-20100401/). For section 10.6.13 "conference.joined" it says the attribute names object1 and object2 have type=string. Isn't this supposed to be type=ECMAScript Object instead? It looks like the same error is in section 10.6.14 (conference.unjoined). Thanks, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
RESULT=ACCEPTED
ACCEPTANCE=IMPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0002.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML Implementation Report: asserts 714 and 715 Date: April 8, 2010 11:04:57 AM EDT To: www-voice <www-voice@w3.org> Hello, We believe that the script 6_1.txml for testing Assers 714 and 715 (required properties sessionid and reason of the ccxml.kill event) is not correct because it breaks the following part of the specification: CCXML specification, Section 9.1: "...however, it is legal for external sources and for events created using <send> to generate standard events. For instance, it is useful to be able to generate a ccxml.kill event to attempt graceful termination of a session from an external context, or from another CCXML session. Platforms SHOULD reject any standard events that do not contain all of the mandatory properties defined in this specification, and SHOULD notify the sender of the rejection (for instance with an error.send event)." We believe that the following statement at line 573, 6_1.txml breaks the specification because it does not contain required properties sessionid and reason: <send target="childSessionId" targettype="'ccxml'" name="'ccxml.kill'" sendid="mySendId"/> Therefore the event SHOULD be rejected and the asserts 714 and 715 cannot pass. Could you please look into this? Best Regards, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Fixed test, but Spec need to be updated, see details of the resolution.
spec was updated back on 7/1. Closing issue.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C2DAF65.6030502@optimsys.cz
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: Recommended addition to the April 2010 CCXML DTD
Date: April 12, 2010 3:04:00 PM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
I'm looking at the CCXML Version 1.0 Candidate Recommendation 1 April 2010
(http://www.w3.org/TR/2010/CR-ccxml-20100401/).
The DTD on the website ( http://www.w3.org/TR/2010/CR-ccxml-20100401/ccxml.dtd)
does not list some attributes of the <ccxml> tag that the test cases use.
For example when 10_2_2_A.txml specifies attributes xmlns="http://www.w3.org/2002/09/ccxml" xmlns:conf="http://www.w3.org/2005/ccxml-conformance" for the <ccxml> tag.
Because those are not listed as optional attributes in the offical DTD, the document will not
validate.
The solution is to add them to the DTD, a snippet of mine is:
<!ATTLIST ccxml version CDATA #REQUIRED
xml:base CDATA #IMPLIED
xmlns CDATA #IMPLIED
xmlns:conf CDATA #IMPLIED >
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0171.html
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April 2010 CCXML Connection class dialogid? Date: April 12, 2010 4:47:37 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, dialogid shows up as a property of the Connection class in assertion #287, but is not listed under http://www.w3.org/TR/2010/CR-ccxml-20100401/#connection.properties The implementation report text for #287 (http://www.w3.org/Voice/2009/ccxml-irp/ ) uses for justification the text: "A Connection Object may have a dialogid property which is the identifier of an associated dialog, if there is one currently using the connection." and then links back to the table of connection properties in an attempt to justify the made-up rule. We don't think this is a simple case of dialogid having been accidentally left off the Connection property table. A Connection can have more than one media input and/or Dialog associated with it at any one time. This is a purpose of the input and outputs properties of the Connection class. This alone would seem to defeat a single dialogid property. For example, consider a call flow where there are 2 simultaneous recordings to different files from a single Connection. These could have been launched via <dialogstart mediadirection="'dialogreceive'"/>. In this case, which dialogid would be "associated" with the single Connection class? The single dialogid property would then be a bogus indication of what is associated with the Connection. It seems that to have a dialogid property associated with the Connection class ignores the one to many relationship that CCXML says it supports. The problem extends beyond the test cases, as some examples in the CCXML Recommendation list *imply* dialogid as a property of the Connection class (7.1, 7.2.1.1, 10.4.2, maybe others). We recommend striking the examples from the Recommendation, and altering any test cases that imply a one-to-one relationship. In 10_2_2_A.txml, we changed: <if cond="session.connections[OutboundID4].dialogid == DialogID"> to be instead: <if cond="session.connections[OutboundID4].input == DialogID && session.connections[OutboundID4].outputs[0] == DialogID"> Thanks, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
1. IR test fixed. 2. Rejected TA #287 3. Fix Spec dialogid/connectionid properties, included in ISSUE-682, see Laura's resolution in - http://lists.w3.org/Archives/Member/w3c-voice-wg/2010May/0068.html and: - http://lists.w3.org/Archives/Member/w3c-voice-wg/2010May/0069.html (perhaps better to create another ISSUE)
fixed by the change set from ISSUE-682
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C051A72.4030600@iivip.com
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April 2010 CCXML test case problem Date: April 9, 2010 6:05:07 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, I'm looking at the CCXML Version 1.0 Candidate Recommendation 1 April 2010 (http://www.w3.org/TR/2010/CR-ccxml-20100401/). The conformance test case file 9_2_4_A.txml which is part of the archive http://www.w3.org/Voice/2009/ccxml-irp/ccxml10-irp-20100331.zip has an error. line 89 reads: <script>t_ASSERT_REASON = assertions[assert_index].reason</script> The fix is to make line 89 be instead: <script>t_ASSERT_REASON = assertions[assert_index].reason;</script> The missing semicolon causes javascript to blow up. Thanks, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Rejected to allow maximum interoperability of ECMAScript handling.
RESULT=REJECTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/20E062AE0851CC41B7FBECC23638796F394646450A@GRFMBX704BA020.griffon.local
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML specification: Application variables Date: April 9, 2010 5:22:09 AM EDT To: www-voice <www-voice@w3.org> Hello, Last year we reported an error in the CCXML specification, Section 8.4. This was tracked as ISSUE-633. The original messages can be found here: http://lists.w3.org/Archives/Public/www-voice/2009OctDec/0022.html In the current Candidate Recommendation the example is already correct. However, the paragraph above the example still contains the following sentence: "Application variables that are not properties, e.g. objects, must be declared." We believe that this sentence is confusing and should be erased. Thanks, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
applied to spec
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0109.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML specification: typo in Appendix K.3 Date: April 13, 2010 4:59:44 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, It looks like there has been a typo in Appendix K.3 introduced in the Candidate Recommendation. The sentence in the second paragraph below the reserved HTTP parameters list reads: For example, a parameter named "1" with a value of "1" represents an object named "a", which has a property "b" with a value of "1". The sentence should be: For example, a parameter named "a.b" with a value of "1" represents an object named "a", which has a property "b" with a value of "1". The problem is in the parameter name: it is "1" and should be "a.b". Thanks, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0107.html
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: problem in test document 8_2_1_A.txml Date: April 17, 2010 7:10:44 AM GMT+08:00 To: www-voice <www-voice@w3.org> Hello www-voice, The 8_2_1_A.txml file from http://www.w3.org/Voice/2009/ccxml-irp/ccxml10-irp-20100331.zip is missing a semicolon: line 110 is <script>t_ASSERT_REASON = assertions[assert_index].reason</script> but should be <script>t_ASSERT_REASON = assertions[assert_index].reason;</script> Thanks -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Prefer to fix this like ISSUE-673
Rejected to allow maximum interoperability of ECMAScript handling.
RESULT=REJECTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0182.html
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: April CCXML: test case conflicts with ECMA rules
Date: April 22, 2010 9:24:03 PM GMT+08:00
To: www-voice <www-voice@w3.org>
Hello voice group,
For test case 798 of 8_4_A.txml, there appears to be an inconsistency with relation to ECMA script rules and scoping rules
laid out in the Recommendation's scoping section ( http://www.w3.org/TR/2010/CR-ccxml-20100401/#Assign ).
Specifically, the Recommendation describes just 4 scopes; session, application, ccxml, and transition.
However, test case 798 indicates that the test designer assumed that "if (statement) { }" results in a new scope, and any
variables declared live inside this new non-existant scope.
The problem is that in ECMA, "if" does not create a scope, and any vars declared get "positioned" in the current scope and set
to undefined prior to execution. Here is the offending test fragment:
------------
<transition event="user.START_ASSERTION_795" state="ASSERTION_NMBR_795">
<assign name="ASSERTION_NUM" expr="'798'"/>
<if cond="id==session.id">
<assign name="application.id" expr="'1'"/>
<if cond="id=='1'">
<var name="id" expr="'2'"/>
------------------
The local position of "id" gets put into the nearest scope, which in this case is the transition level scope.
When the script runs, this means that "id" exists but has the value undefined when <if cond="id==session.id"> runs,
so the test always fails.
To the test designer the javascript equivalent of the test fragment is:
--------------------------------------------------
if(id==session.id)
{
application.id = '1';
if( id=='1' )
{
var id = '2';
}
}
--------------------------------------------------
But in reality to ECMA the xml becomes:
------------------------------------------
var id=undefined; // because this is the scope; not the if {} and id has not been assigned yet
if(id==session.id) // always fails now
{
application.id = '1';
if( id=='1' )
{
id = '2';
}
}
-------------------------------------------
We don't see in the Recommendation where "if" is supposed to create a new scope, so we fall back on ECMA
rules, where "if" does *not* create a scope. In theory a block scope could be created after "if" with the "let"
keyword, but we doubt that was intended.
We recommend the test be deleted or modified.
As a followup, when the test fails, it fails to record the error properly because in the .txml,
there is:
<log expr="LogPrefix + ' FAIL session.id/id=' + id + ' expected session.id'"/>
and LogPrefix is undefined.
Thanks
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Agreement on resolution 2010-07-02. Test to be changed by Serguei by aligning with RJ proposal. Loquendo to review it.
New version of 8_4_A.txml has been circulated
Test change approved. Pending Spech change.
updated spec. Closing issue.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0022.html
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: April CCXML: bad function in test document 6_1.txml
Date: April 15, 2010 11:52:53 PM GMT+08:00
To: www-voice <www-voice@w3.org>
Hello www-voice,
There is some bad javascript in 6_1.txml of http://www.w3.org/Voice/2009/ccxml-irp/ccxml10-irp-20100331.zip
The segment of code that reads
<var name="counter" expr="0"/>
<script>
function next()
{
ccxml.counter = ccxml.counter + 1;
return ccxml.counter;
}
</script>
should be instead
<var name="counter" expr="0"/>
<script>
function next()
{
counter = counter + 1;
return counter;
}
</script>
The fact that ccxml is not a defined object before being referenced causes the javascript to burst.
Thanks
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
RESULT=REJECTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0042.html
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: bad assignments in test document 6_1 Date: April 16, 2010 12:02:53 AM GMT+08:00 To: www-voice <www-voice@w3.org> Hello www-voice, There is some illegal CCXML in 6_1.txml and child_1.ccxml from http://www.w3.org/Voice/2009/ccxml-irp/ccxml10-irp-20100331.zip . In 6_1.txml, the line <assign name="ccxml.var2" expr="222"/> should instead be <assign name="application.var2" expr="222"/> and in child_1.ccxml the references to ccxml.var2 should also be instead to application.var2. That particular case seems to be verifying that application scope variables set in the parent are not reflected in the child. That's good, but the wrong variables are being checked. The references to an object that doesn't exist (and even if present in parent would not exist in the child) cause javascript in both parent and child to combust. Thanks -- Chris Davis Interact Incorporated R&D 512-502-9969x117
RESULT=REJECTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0043.html
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: problem found in test document 6_1.txml Date: April 15, 2010 11:47:16 PM GMT+08:00 To: www-voice <www-voice@w3.org> Hello www-voice, There are some missing + symbols in the javascript of 6_1.txml of http://www.w3.org/Voice/2009/ccxml-irp/ccxml10-irp-20100331.zip line 477 reads: <conf:fail reason="'expr of ccxml.exit : ' event$.expr + ' does not match the expr of exit tag (oops!) '"/> but should be <conf:fail reason="'expr of ccxml.exit : ' + event$.expr + ' does not match the expr of exit tag (oops!) '"/> Same type of error on line 489: <conf:fail reason="'reason of ccxml.exit : ' event$.reason + ' does not match the real exit reason (must be exit) '"/> needs to be <conf:fail reason="'reason of ccxml.exit : ' + event$.reason + ' does not match the real exit reason (must be exit) '"/> The missing + symbols cause the javascript to explode. Thanks -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Resolution accepted. Test fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0135.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: "Class" definition Date: April 23, 2010 5:29:59 PM GMT+08:00 To: www-voice <www-voice@w3.org> Hello, We believe the definition of Class at the end of Section 3.4 Definitions is not correct: Reserved ECMAScript property 'prototype.constructor' MUST reference the class constructor object, so in the example above, 'MyConnection.prototype.constructor == Connection'. According to the ECMA Script specification, we believe the class constructor object should be referenced through 'constructor' instead of 'prototype.constructor': Reserved ECMAScript property 'constructor' MUST reference the class constructor object, so in the example above, 'MyConnection.constructor == Connection'. Thanks, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Applied spec change 20101007. Waiting Petr acceptance to close this issue.
Resolution sent and applied to Sect. 3.4 and accepted 2010-10-08. Paolo.
RESULT=DROPPED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010OctDec/0006.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: Dialog properties inconsistency Date: April 23, 2010 10:50:18 PM GMT+08:00 To: www-voice <www-voice@w3.org> Hello, There is an inconsistency in description of the Dialog object in the the last CCXML specification. On one hand, connectionid and conferenceid properties were removed from Section 7.4 Dialog Object Properties. Analogously, dialogid was removed from Section 10.2.2 Connection Object. On the other hand, the following statement was added into Section 7.2.1.1 <dialogprepare> Overview: "If the connectionid or conferenceid attributes are specified on <dialogprepare> the Dialog Object's connectionid/conferenceid properties MUST be set to the appropriate values. Additionally the dialogid attribute of the Connection Object MUST be set to the dialogid of the new Dialog." This text does not correspond to the changes in 7.4 and 10.2.2. Furthermore, it is not stated in <dialogstart> overview either. Therefore we recommend to remove the statement from 7.2.1.1. Thanks, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
See Spec changes in Laura's proposal [(second email of this thread).
fixed in spec
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0118.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML Implementation Report: couple of problems in scripts Date: April 13, 2010 8:51:34 PM GMT+08:00 To: www-voice <www-voice@w3.org> 1) Assignment without declaration. Script 8_2_2_A.txml, Assertions 757, 758, 759. The script contains the following assignments without declaring variables var2 and var3: var2 = var1; var3 = myAry["ary"]; CCXML specification contains the following statement: It is illegal to make an assignment to a variable that has not been explicitly declared using <var> or a var statement within a <script>. So the code above is illegal.
Resolution accepted. Fixed test.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0193.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML Implementation Report: couple of problems in scripts Date: April 13, 2010 8:51:34 PM GMT+08:00 To: www-voice <www-voice@w3.org> 2) Invalid value of the <script> timeout parameter. Script 8_2_3_A.txml. The script contains the following statement at line 180: <script src="sleeper.ircgi" timeout="'1s'"/> Since the timeout parameter has type 'Character string' and not 'ECMAScript Expression' value of the timeout parameter shouldn't contain apostrophes: <script src="sleeper.ircgi" timeout="1s"/>
Resolution accepted. Test Fixed.
Resolution accepted. Test Fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0192.html
Resent-From: www-voice <www-voice@w3.org>
From: Petr Kuba <kuba@optimsys.cz>
Subject: CCXML Implementation Report: couple of problems in scripts
Date: April 13, 2010 8:51:34 PM GMT+08:00
To: www-voice <www-voice@w3.org>
3) Incorrect VXML script version.
Script 7_3_1.vxml.
This VXML script is declared with version="2.0" but it contains attribute 'type' in <transfer> which is supported only in VoiceXML 2.1:
<transfer name="transferRequest" type="bridge" connecttimeout="10s"
destexpr="destURI" aaiexpr="data">
So the script version should be probably 2.1.
Resolution accepted. Test fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0194.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML Implementation Report: couple of problems in scripts Date: April 13, 2010 8:51:34 PM GMT+08:00 To: www-voice <www-voice@w3.org> 4) Wrong I/O processor type. 8_3_B.txml, Assertion 1033. See the following code at line 148: <if cond="typeof(session.ioprocessors['basichttp']) == 'string' && typeof(session.ioprocessors['createsession']) == 'string'"> <script>assertions[assert_index].P_F = s_PASS;</script> <else/> <script> assertions[assert_index].P_F = s_FAIL; assertions[assert_index].reason = 'Objects in session.ioprocessors are improperly typed;' + 'first object has type ' + typeof(session.ioprocessors['basichttp']) + ', second object has type ' + typeof(session.ioprocessors['ccxml']) + '; both should be of type string.'; </script> </if> The <if> tag references I/O processors 'basichttp' and 'createsession' but the <script> tag references 'basichttp' and 'ccxml'. The 'ccxml' value in <script> is incorrect, it should be 'createsession'.
Resolution accepted. Test fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0195.html
Resent-From: www-voice <www-voice@w3.org>
From: Petr Kuba <kuba@optimsys.cz>
Subject: CCXML Implementation Report: couple of problems in scripts
Date: April 13, 2010 8:51:34 PM GMT+08:00
To: www-voice <www-voice@w3.org>
5) Relative target URI in <send> using basichttp.
Script 9_2_5_B.txml.
The CCXML specification, Appendix K.4 states:
The target attribute MUST be set to the access URI of the external
component.
The script assumes that the target URI is relative to the processed CCXML document:
<send targettype="'basichttp'" target="'9_2_5_B_500.jsp'"
name="'user.ass_570'" sendid="send_id_1"/>
However, it is not stated anywhere that the target in basichttp should be relative to the CCXML document. Is this desired feature? Then it should be stated in Appendix K.
Rejected. Resolution accepted.
RESULT=REJECTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0196.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: CCXML Implementation Report: couple of problems in scripts Date: April 13, 2010 8:51:34 PM GMT+08:00 To: www-voice <www-voice@w3.org> 6) Typo in xslt. File jumbo_test-ccxml-sample.xslt. This is a minor typo which doesn't cause any problem but the '3' character in 'unrea3chable' is probably unintended: <var name="uri_UNREACHEABLE" expr="'http://10.255.255.254/unrea3chable'"/>
RESULT=REJECTED
ACCEPTANCE=IMPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0054.html
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: test id 555 incorrect? Date: April 27, 2010 2:45:46 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, Assertion #555 appears to test that the error.allowed event's id is set correctly after a <cancel> of an ID that does not exist. It is my understanding that "id" should be set to the value passed to the failing <cancel>'s sendid. <cancel sendid="send_id_1"/> <!-- is bogus --> The test currently checks <if cond="event$.id==session.id"> which looks to be incorrect. I'm assuming it should be equivalent to send_id_1. This appears in 9_2_5_A.txml. Thanks -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Rejected TA #555. Resolution accepted
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0148.html
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: April CCXML: test case 882 error?
Date: April 27, 2010 4:28:29 PM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
Test #882 seems to test that a conference ID is a legal URI.
It uses a cryptic value passed to "match":
---------
if (confid.match(/^([A-Za-z]:\/\/(.*\/)+)?(\w)+$/) != undefined )
------------------------
I ran some sample URIs from RFC2396 through the same "match" usage
as the test case and am told URIs are not URIs.
Examples that it claims are not URIs:
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.math.uio.no/faq/compression-faq/part1.html
<html>
<body>
<pre>
<script type="text/javascript">
var confid = 'ftp://ftp.is.co.za/rfc/rfc1808.txt';
if (confid.match(/^([A-Za-z]:\/\/(.*\/)+)?(\w)+$/) != undefined )
{
document.write( confid + ' is a URI' );
}
else
{
document.write( confid + ' is NOT a URI' );
}
</script>
</pre>
</body>
</html>
This is part of 10_5_5_A.txml.
Thanks
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: Re: April CCXML: test case 882 error? [should be 852]
Date: April 27, 2010 4:32:02 PM EDT
To: www-voice <www-voice@w3.org>
Correction: the test case # is 852, not 882
Chris Davis wrote:
Hello www-voice,
Test #882 seems to test that a conference ID is a legal URI.
It uses a cryptic value passed to "match":
---------
if (confid.match(/^([A-Za-z]:\/\/(.*\/)+)?(\w)+$/) != undefined )
------------------------
I ran some sample URIs from RFC2396 through the same "match" usage
as the test case and am told URIs are not URIs.
Examples that it claims are not URIs:
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.math.uio.no/faq/compression-faq/part1.html
<html>
<body>
<pre>
<script type="text/javascript">
var confid = 'ftp://ftp.is.co.za/rfc/rfc1808.txt';
if (confid.match(/^([A-Za-z]:\/\/(.*\/)+)?(\w)+$/) != undefined )
{
document.write( confid + ' is a URI' );
}
else
{
document.write( confid + ' is NOT a URI' );
}
</script>
</pre>
</body>
</html>
This is part of 10_5_5_A.txml.
Thanks
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Rejected TA #852. Resolution accepted.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0197.html
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: Dialog and Connection semantic error handling Date: May 7, 2010 5:43:20 AM EDT To: www-voice <www-voice@w3.org> Hello, Could you please clarify the following issues? Description of the connectionid attribute of the <dialogstart> element states: If the attribute value is invalid an error.semantic event must be thrown. The question is whether this statement applies only to ECMAScript errors such as accessing non-declared variable or also to the case where unknown connection is referenced. For example: <dialogstart ... connectionid="'fake_conn_id'"/> Value of connectionid will be evaluated correctly in this case but there is no connection with the given id. Shall error.semantic be thrown in this case? Another question is what shall be done when error.semantic is thrown when executing <dialogstart>. Is it allowed to call <dialogstart> again, shall <dialogterminate> be called, or shall the Dialog Object be destroyed automatically? Please note that these questions apply also to <dialogprepare> and connection-related elements and the following statement is related to this issue: 10.2.4: Connection Operations If the element cannot be evaluated, for example if the referenced connectionid contained an invalid ECMAScript expression, then an 'error.semantic' event is thrown - as is the case for all CCXML elements. The error.semantic event MUST NOT change the state of the associated Connection Object(s). So if the dialog behaves the same way as connection it should not be destroyed automatically after error.semantic. Thanks for clarification, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
RJ needs to send public reply to check error lang section (see minutes on 5/27)
Clarification by email, no change neither in spec nor in IR. Accepted resolution 2010-09-06. Paolo.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0152.html
RESULT=CLARIFICATION
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: minor issue in 8_2_3_A.txml Date: May 7, 2010 3:12:56 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, <fetch next="'ass_772_aux.txml'"/> should probably be <fetch next="'ass_772_aux.ccxml'"/> Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Test fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0149.html
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: Two breaks in 10_5_8_A.txml Date: May 10, 2010 4:01:15 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, Today we tickle your inbox with 2 breaks in a CCXML conformance test: 1) <assign name="current_state" expr="ASSERTION_NMBR_858_DESTROYING_CONFERENCES"/> should instead be <assign name="current_state" expr="'ASSERTION_NMBR_858_DESTROYING_CONFERENCES'"/> 2) <send targettype="'ccxml'" target="session.id" name="user.A979_finish" delay="'3s'"/> should instead be <send targettype="'ccxml'" target="session.id" name="'user.A979_finish'" delay="'3s'"/> The missing tick marks cause the javascript to explode. Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Test fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C052D93.4070700@iivip.com
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: break in 10_5_8_A_978.txml Date: May 10, 2010 4:09:04 PM EDT To: www-voice <www-voice@w3.org> Cc: Rachel Muller <rachel.muller@aspect.com> Hello www-voice, <transition event="error.conference.unjoined" state="ASSERTION_NMBR_978"> should instead be <transition event="error.conference.unjoin" state="ASSERTION_NMBR_978"> There is no such event "error.conference.unjoined" in the Recommendation. The error case in question delivers error.conference.unjoin to the offending session. Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Test fixed.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C052DB8.3040102@iivip.com
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: 2 bugs in 8_3_B.txml Date: May 11, 2010 4:43:02 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, 1) <if cond="session.dialogs[dID].src.match(/^(http)|(file):\/\/.+\/6_2_686.ccxml&/) != null"> won't work to check the existance of the proper URI of dialog.vxml. 2) the <dialogterminate> results in both dialog.exit and conference.unjoined. The .txml has no handler for conference.unjoined, which causes the catch-call transition to queue up another user.PREPARE_NEW handler, triggering its transition to index past the end of assertions[] array. Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Fixed test.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/20E062AE0851CC41B7FBECC23638796F394689E76D@GRFMBX704BA020.griffon.local
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: 3 bugs in 7_1.txml Date: May 12, 2010 4:33:01 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, 1) maxage and maxstale attributes of the <dialogprepare> tag are supposed to be strings, so <dialogprepare src="VxmlFile + '.' + 'vxml' " dialogid="DialogID" connectionid="ConnectionID" maxage="5" maxstale="10" type="'application/voicexml+xml'" method="'GE' + 'T'" enctype="'application/x-www-form' + '-urlencoded'" parameters="param1 param2 param3"/> should instead be <dialogprepare src="VxmlFile + '.' + 'vxml' " dialogid="DialogID" connectionid="ConnectionID" maxage="'5'" maxstale="'10'" type="'application/voicexml+xml'" method="'GE' + 'T'" enctype="'application/x-www-form' + '-urlencoded'" parameters="param1 param2 param3"/> 2) the immediate attribute of <dialogterminate> is supposed to be a string, not boolean so <dialogterminate dialogid="DialogID" immediate="true"/> should instead be <dialogterminate dialogid="DialogID" immediate="'true'"/> (same where it is false) 3) There is no transition handler to catch and ignore conference.unjoined, so the test logic gets screwed up by queuing events out of order. Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Fixed test, spec must be changed in the definition of immediate attribute in Section 7.2.3.2.
spec was updated and chris accepted resolution
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C2DEA69.8020504@iivip.com
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: April CCXML: no unjoined for 859 in 10_5_8_A.txml
Date: May 24, 2010 3:34:19 PM EDT
To: www-voice <www-voice@w3.org>
Cc: Rachel Muller <rachel.muller@aspect.com>
Hello www-voice,
The test sheet needs a do-nothing transition:
<transition event="conference.unjoined" state="ASSERTION_NMBR_859">
</transition>
or assertion #977 never runs.
The test does not account for the unjoined as a result of a previous <dialogterminate>
in the same assertion(#859).
Regards,
Chris
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Fixed test.
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Member/w3c-voice-wg/2010Jul/0037.html
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: error in 7_6_2.txml Date: May 21, 2010 10:28:16 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, This jumbo test sheet needs a do-nothing transition for conference.unjoined; as written the test errors out upon conference.unjoined. That is, assertion 889 will show as PASS in the logs but you won't see the PASS 890 because the queue logic gets confused due to the catch all transtion (event="*"). The unjoined occurs as a result of the VoiceXML dialog terminating. Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Fixed test.
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Member/w3c-voice-wg/2010Jun/0076.html
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: 3 problems with manual tests (10_5_7_A_*.txml) Date: May 18, 2010 3:51:15 PM EDT To: www-voice <www-voice@w3.org> Cc: Rachel Muller <rachel.muller@aspect.com> Hello www-voice, There are 3 issues with the manual tests comprising the CCXML test cases: 1) entertone/exittone on the <join> tag specifies a boolean instead of a character string. 10.5.7.2 says of those attributes that they are "An ECMAScript expression that returns a character string". They are probably a good candidate to stay strings, as they can also reference WAV URIs. 2) 10_5_7_A_110.txml references exittone="'manual_tests/voice.wav'". In order to be consistent with 10_5_7_A_104.txml and work with the provided directory structure it should instead be exittone="'voice.wav'" 3) 10_5_7_A_110.txml does an <exit> upon conference.unjoined but the test asserts that the caller should hear the exittone of the unjoining conference member. This *implies* that the exittone should be played *before* the member exits and then generates the conference.unjoined, but the recommendation doesn't say this. Our browser actually removes the member first then plays the tone, hence the confusion. As a work around we moved the exit in the test 3 seconds after the unjoined. We recommend clarifying in 10.5.7.2 when the tone is played and to whom. In other words, are the enter and exit tones played BEFORE add/remove or AFTER. Also, are the tones played to everyone in the conference including the party entering/leaving? Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Fixed test for #1 and #2. Point #3 requires spec changes, see resolution for details.
Spec change has been applied. Closing in tracker.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Member/w3c-voice-wg/2010Aug/0055.html
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: April CCXML: 3 errors in 10_5_7_A.txml
Date: May 18, 2010 4:28:24 PM EDT
To: www-voice <www-voice@w3.org>
Cc: Rachel Muller <rachel.muller@aspect.com>
Hello www-voice,
Here are the errors:
1) <if cond="sessions.conferences[A854_confid1].bridges.length == 1
There is no sessions scope. That needs to be session with no s
2) Assertion #854 as written will never work (see above fragment). The bridges property of the
Conference object is defined in 10.3.1 as "an ECMAScript associative array". It is referenced
by conference ids which are by definition URIs. The ECMA .length of an associative array
is always zero.
When you account for breaks 1) and 2), the broken segment:
<if cond="sessions.conferences[A854_confid1].bridges.length == 1 && sessions.conferences[A854_confid2].bridges.length == 1">
thus becomes
<if cond="session.conferences[A854_confid1].bridges[A854_confid2] != undefined && session.conferences[A854_confid2].bridges[A854_confid1] != undefined">
3) TC#855 tries to look at the dialog objects to make sure the switching is correct.
However, as written it doesn't account for all the switching. Specifically, the switching
picture by the time #855 rolls around is:
A855_dialogid1 <====> A855_dialogid2
A855_dialogid1 --> general_connid
A855_dialogid2 --> A855_connid1
yet the check is written like this:
<script><![CDATA[A855_passed = (session.dialogs[A855_dialogid1].input == A855_dialogid2 &&
session.dialogs[A855_dialogid2].input == A855_dialogid1 &&
session.dialogs[A855_dialogid1].outputs[0] == A855_dialogid2 &&
session.dialogs[A855_dialogid2].outputs[0] == A855_dialogid1);
]]></script>
To check everything, the test should be something like this:
<script><![CDATA[
function outputpresent( haystack, needle, numElements )
{
var rc = false;
for(i=0; i< numElements; i++ )
{
if( haystack[i] == needle )
{
rc = true;
break;
}
}
return rc;
}
A855_passed = false;
if( session.dialogs[A855_dialogid1].outputs.length == 2 && session.dialogs[A855_dialogid2].outputs.length == 2)
{
if( session.dialogs[A855_dialogid1].input == A855_dialogid2 && session.dialogs[A855_dialogid2].input == A855_dialogid1 )
{
if( true == outputpresent( session.dialogs[A855_dialogid1].outputs, general_connid, 2 ))
{
if( true == outputpresent( session.dialogs[A855_dialogid1].outputs, A855_dialogid2, 2 ))
{
if( true == outputpresent( session.dialogs[A855_dialogid2].outputs, A855_connid1, 2 ))
{
if(true == outputpresent( session.dialogs[A855_dialogid2].outputs, A855_dialogid1, 2 ))
{
A855_passed = true;
}
}
}
}
}
}
]]></script>
//------------
Note that as written, the check currently leaves off some of the switch paths and assumes the secondary switch
paths are in index position 0. Our browser adds new paths to the END of the array. If other behavior is desired
we suggest it be placed in the Recommendation.
Regards,
Chris
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Resolution accepted, but modified tests might be sent to the Chris to double-check them.
Test Changes approved by Chris. Issue closed.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C349EC4.4010003@iivip.com
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: problem w/7_4.txml Date: May 18, 2010 4:33:46 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, The test sheet 7_4.txml needs a do nothing transition for conference.unjoined. As written, it gets confused and errors out when receiving the unjoins associated with a <dialogterminate> Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Fixed test.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C0E694B.5000400@iivip.com
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: 4 issues w/7_2.txml Date: May 14, 2010 9:38:31 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, 1) note: dialogterminate has the immediate boolean/string problem 7.2.3.2 says of the immediate attribute that it is "An ECMAScript expression which returns a character string," It seems simpler for the "type" to be "ECMA script expression returning boolean", but that is not the way things are currently written. 2) <var name="paramcc3='Hello world'"/> should be <var name="paramcc3" expr="'Hello world'"/> As written, it causes ECMA errors 3) When <dialogterminate> is called, the browser generates as a side effect conference.unjoined. This is consistent with 7.2.3.1, which says: "The platform MUST tear down any existing bridges to the dialog and send a conference.unjoined to the CCXML document once the media paths have been freed." The problem is that the script is not expecting this, and treats the conference.unjoined as an error 4) <dialogstart> has maxage/maxstale passed as integers not strings. A string result of the ECMA script expression is implied in 7.2.2.2 where it says "The character string returned must be interpreted as a time interval." It seems simpler for the "type" to be "ECMA script expression returning integer", but that is not how it is written. Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Fixed tests, but linked to spec resolution of ISSUE-697
Spec was updated as part of ISSUE-697 - Chris accepted the change. Closing issue.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C2DEAEC.5000503@iivip.com
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: April CCXML: 3 problems w/7_5.txml Date: May 18, 2010 3:36:44 PM EDT To: www-voice <www-voice@w3.org> 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
Fixed test, but linked to spec resolution of ISSUE-697
Spec was updated as part of ISSUE-697 edits. Closing in tracker.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C2DEC42.2090007@iivip.com
RESULT=MIX
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: attribute 'id' of the error.notallowed event Date: May 5, 2010 11:03:45 AM EDT To: www-voice <www-voice@w3.org> Hello, Usage of the error.notallowed event in the <cancel> element should be probably clarified. Overview of the <cancel> element in 9.2.5.1 states: ...the <cancel> request MUST fail and an error.notallowed event MUST be delivered to the event queue... Description of the 'id' attribute of the error.notallowed event states: The ID, if specified in the element being executed, of the affected connection, dialog, session, or conference. The question is: shall the 'id' attribute of the error.notallowed event contain id of the event for which <cancel> failed? If yes, it should be explicitly stated in 9.2.5.1 and description of the 'id' attribute of the error.notallowed event should list also event (besides connection, session and others). Thanks, Petr Kuba -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C91BC06.3020802@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: wrong assumption in 7_1, assertion 463, 467 Date: May 27, 2010 10:43:25 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_1.txml, assertions 463 and 467 assume that <dialogprepare> results in error.dialog.notprepared if the referenced vxml document doesn't exist. However, the Specification states: "the CCXML implementation MUST as a minimum, note the values provided in the <dialogprepare> attributes, ..." which means that it is not required to load the document during <dialogprepare>. Therefore these assertions may fail although the features are supported. On the other hand, I understand that it is hard to test these assertions without the assumption. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution accepted. No change.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C1230E3.9090103@optimsys.cz
RESULT=REJECTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: variable not declared in 6_3 Date: May 27, 2010 9:55:58 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 6_3.txml, the 'result' variable is not declared in the extractCurrentDir() function. I assume that it should be. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Fixed test.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C12313F.3050308@optimsys.cz
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C12313F.3050308@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML, 7_1: attribute enctype used with the value of the method "post" in <dialogprepare> Date: May 27, 2010 10:30:46 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_1, assertion 456, the 'enctype' attribute is used in <dialogprepare> although the value of the 'method' attribute is "post". According to the Specification, 7.2.1.2, the 'enctype' attribute is "Valid only when the value of the method is 'post'". What does it mean that the atribute is "valid"? Does it mean that 'enctype' MUST not be used if the value of the 'method' is "get"? Or does it mean that 'enctype' can be used and is just ignored? Furthermore, we recommend to state explicitly that the value of the 'method' attribute is case-insensitive in all elements where this attribute appears. This is stated in Appendix L3 but not in the description of elements. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
This ISSUE-710 is not a duplicate of ISSUE-730. ISSUE-710 asks for possible spec changes: (a) state explicitly that enctype is ignored if method is not POST; (b) state explicitly that method attribute is case-insensitive. No IR changes are required, only spec clarifications. Paolo.
I am waiting to see if he accepts the change that enctype is ignored if method is not POST. I would rather not do the case-insensitive change as thats a giant rats nest of changes that will come if thats allowed.
Resolution accepted 2010-08-30 and spec change applied. Paolo
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C7B767C.1030705@optimsys.cz
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML 7_3: maxtime unlimited value in dialog.transfer Date: May 28, 2010 4:20:34 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_3.txml, assetion 420, a maxtime property of the dialog.transfer event is tested. According to the specification, 7.3.5, timeout is: "A string in CSS2 format that specifies the maximum amount of time the transfer may stay connected. If the amount of time is unlimited the value must be 0s." According to CSS2, zero time can be represented as 0s or as 0ms. Therefore we recommend to allow both these values to represent unlimited time - both in the specification and in the test. It can be useful e.g. in situations where the time is computed by a function that works with ms. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Fixed test.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C123174.3010200@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org>
From: Petr Kuba <kuba@optimsys.cz>
Subject: April CCXML: invalid script 7_4.vxml
Date: May 28, 2010 5:30:21 AM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
In 7_4.vxml, <form> element contains child element <prompt> which is invalid. It is necessary to encapsulate <prompt> into <block>:
<?xml version="1.0" encoding="UTF-8" ?>
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml" xml:lang="en-US">
<var name= "data" expr="'HiFolks'"/>
<catch event="connection.disconnect.hangup">
<exit namelist="data"/>
</catch>
<form>
<block>
<prompt>
<break time="10s"/>
</prompt>
</block>
</form>
</vxml>
Thanks,
Petr
--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@optimsys.cz
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz
Fixed test.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C1231EA.80209@optimsys.cz
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML 8_2_1_B: referencing undeclared variable Date: May 28, 2010 6:01:13 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 8_2_1_B.txml, the bool_738_ccxml_7 variable is declared: <var name="bool_738_ccxml_7" expr="false"/> This variable is then reference in 8_2_1_B_739.txml where it is not declared. This causes an error.semantic and thus test failures. Since the variable is declared in the ccxml scope it cannot be shared by several documents. It doesn't make sense to assign value to bool_738_ccxml_7 in 8_2_1_B_739.txml. We recommend to remove the assignment from 8_2_1_B_739.txml. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Fixed test.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C123247.8030209@optimsys.cz
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: format of the name attribute in <send> Date: May 28, 2010 7:00:46 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, Description of the name attribute in <send> states: "An ECMAScript expression which returns a character string that indicates the event name being generated. The event name may include alphanumeric characters and the "." (dot) character. The first character MUST NOT be a dot or a digit." The problem is that tests and examples contain also the "_" (underscore) character which is not covered by the description. We recommend to add this character to the description of the name attribute. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
resolved in spec
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E35FF.4080401@optimsys.cz
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML 10_5_8: undeclared variable Date: May 28, 2010 7:11:45 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 10_5_8_A.txml, the hints variable is not declared. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Fixed test.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C123266.4060705@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML 7_3: required property reason in dialog.terminatetransfer Date: May 28, 2010 4:46:44 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_3.txml, assetion 430 tests presence of the reason property in dialog.terminatetransfer. May I ask why this property is required according to the Specification? VoiceXML specification doesn't provide any reason for the terminate transfer request and therefore only some general description can be used in this case. It is obviously not very useful. I believe the same problem can appear for other dialog systems besides VoiceXML. We would recommend to make the reason property optional. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C91BD26.9010400@optimsys.cz
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: <fetch> clarification Date: May 28, 2010 10:48:35 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, We've got several comments regarding April modifications in document fetching: 1) Section 6.2.7.1 states: "If the platform does not support the content type returned from a <fetch> request but the fetch does successfully complete (for example HTTP 2xx response code) the platform MUST still throw a fetch.done event for the fetchid." I believe that this statement is invalid if the mode value is "processed". In this case the following statement should be applied: "Note that even if content is successfully fetched, errors in processing fetched content (for instance, a CCXML document with a syntax error) may result in an error.fetch being thrown." Please clarify this. ----------- 2) 6.3.2 fetch.done: How shall content attribute behave in processed mode? The description states: "If the CCXML browser can not represent the content in ECMAScript (for example some content that was fetched in processed mode) this may be ECMAScript undefined." This implies that for some content in processed mode this atribute can contain a representation of the fetched content. Could this be more specific? When shall the content be specified and when not in processed mode? For instance, when fetching a CCXML document in processed mode, shall a text representation be also included in the content attribute? ----------- 3) 6.3.3 error.fetch: What are content and contenttype attributes good for in this event? I can imagine that there are situations where we obtain contenttype and then content fetching fails. Regarding the content attribute, how can it be used here? The only situation I can imagine is a content that was downloaded but parsing failed (in processed mode). Is it correct? Please clarify on this. Furthermore, all the attributes in error.fetch are required although they are not always available. When we fail to access the document (e.g. the server is unreachable) we don't have neither content nor content type. These attributes will be undefined. Wouldn't it be better to make them optional? Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
RESULT=CLARIFICATION
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C931278.7050504@optimsys.cz
Resent-From: www-voice <www-voice@w3.org>
From: Petr Kuba <kuba@optimsys.cz>
Subject: April CCXML 9_2_3_B: handling of invalid event name in <send>
Date: May 31, 2010 10:51:08 AM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
In 9_2_3_B.txml, assertion 1247 expects that invalid name attribute value ('.name_prepare_new') results in throwing an error.send.* event (error.send.failed).
In this case we would expect an error.semantic event to be thrown because it better fits the situation where an attribute has an incorrect value:
"9.3.2: error.semantic
This error event MUST be thrown when there is a semantic error in a CCXML element ( e.g. passing an incorrect value for an attribute, etc.)."
error.send.* event seem to be used in situation where delivery of events fails for some "dynamic" reason, e.g. target unavailable.
Thanks,
Petr
--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@optimsys.cz
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz
Resolution accepted 2010-08-30. Spec change already applied. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C7B8668.6080400@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice@w3.org From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML: Number of connection.merged events Date: July 2, 2010 4:56:56 AM EDT To: www-voice <www-voice@w3.org> Hello, I've just noticed the following text in the CCXML specification, Section 10.5.10.2 (Merge Overview): "A connection.merged event MUST be generated on each of the two calls affected by a merge." Is there any reason to generate two events although both connections must be in the same CCXML session? Further more, implementation report (e.g. assert 285) expects also only one connection.merged and it would fail in case of two events. My recommendation is to change the specification to gnerate only one connection.merged. Otherwise it is necessary to modify the implementation report script(s). Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution accepted 2010-08-20, but request about spec change. From our point of view we should defer it to a future version. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C91C29B.4020509@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: April CCXML, 7_2: combination of attributes in <dialogstart> Date: May 27, 2010 11:29:50 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_2.txml, assertions 340, 342, 347, 349, 366, 368, 370, 373, and 1186 test the following features in <dialogstart>: (1) The src, type, namelist, maxage, maxstale, enctype, method, and parameters attributes MUST NOT be specified in conjunction with the prepareddialogid attribute. (2) If the prepareddialogid attribute is specified and any attribute values conflict with the values specified in the <dialogprepare> element this MUST result in the throwing of an error.dialog.notstarted event. ------ We believe that the incorrect combination of mutually exclusive attributes in (1) should be handled according to 9.5.1 Fetching & compilation errors: "Errors that occur in trying to load and compile a CCXML document, such as ... validation errors (Including checks for mutually exclusive attributes...)" Therefore these errors should result in error.createccxml or error.fetch instead of error.dialog.notstarted. ------ Thus (2) could apply only on the connectionid and conferenceid attributes. However, the Specification states in description of these attributes: "If the dialog was previously prepared using a <dialogprepare> element with a connectionid or conferenceid specified, and this attribute is also specified, execution of the <dialogstart> MUST fail with an error.dialog.notstarted event." Therefore the conflict in (2) cannot occur because it is not allowed to use connectionid / conferenceid in both <dialogprepare> and <dialogstart>. We recommend to remove the statement (2) from the specification (Section 7.2.2.1, paragraph 4). Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution Accepted 2010-09-23 by Petr. Loquendo will work on test-suite. Proposed spec changes in: http://lists.w3.org/Archives/Member/w3c-voice-wg/2010Sep/0080.html 1. Script - Sect 8.2.2.2: ATTRIBUTES: fetchid, timeout, maxage, maxstale "This attribute is only valid in conjunction with the src attribute[[, otherwise ignored.]]" 2. Createcall - Sect. 10.5.4.2 Two options: a. Remove default value for joindirection in table and DTD/Schema b. (preferred) Change wording in Attribute Constraints and keep default value: OLD: "If this attribute is specified the joinid attribute MUST be present." NEW: "This attribute is only valid in conjunction with the joinid attribute, otherwise ignored." Paolo
changes applied to the spec
Spec changes applied to internal draft 20101007. Resolution already accepted by Petr. Issue closed.
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010JulSep/0183.html
RESULT=ACCEPTED
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: script child_9.ccxml in 6_1not terminating Date: July 19, 2010 10:17:16 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 6_1, the session running child_9.ccxml script is not terminated and survives end of the test. We assume that all the sessions that survive end of a test signify a problem that should be investigated. Therefore we recommend to kill the session at the end of test to keep the the test clear. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E41B8.30403@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: incorrect script version in 7_2 Date: July 19, 2010 11:08:26 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, The following VXML scripts are declared with version="2.0" but they contain features supported only in VoiceXML 2.1: 7_2_data.vxml 7_2_dataConf.vxml 7_2_disconnect.vxml In 7_2_data.vxml and 7_2_dataConf.vxml, the <data> element is used. This element is not supported in VoiceXML 2.0. In 7_2_disconnect.vxml, the <disconnect> element contains attribute 'namelist' which is not supported in VoiceXML 2.0. We recommend to change the scripts version to 2.1. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E4221.2020408@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: missing 'var' in jumbo_test-ccxml-sample.xslt Date: July 26, 2010 2:08:13 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, in jumbo_test-ccxml-sample.xslt, line 114 the rr variable is not declared. Further more, it is missing ';' at the end of line. The code should be: var rr = Object(); Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E32AB.6060908@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: invalid script 7_1_2.vxml Date: July 26, 2010 2:48:57 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_1_2.vxml, <form> element contains child element <prompt> which is invalid. It is necessary to encapsulate <prompt> into <block>. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E3B34.7070206@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 'dialog.user.test' missing required attributes in 7_2 Date: July 26, 2010 3:15:50 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_2, the 'dialog.user.test' event is rejected because it doesn't contain required attributes eventid, eventsource, and eventsourcetype (according to the CCXML specification, sections 9.4.2). Section 9.1 states: "Platforms SHOULD reject any standard events that do not contain all of the mandatory properties defined in this specification, and SHOULD notify the sender of the rejection (for instance with an error.send event)." Who is responsible for inserting the required attributes in this case where the event is sent from a VoiceXML application using basichttp? I assume that it is responsibility of the VoiceXML application. Please clarify and fix the test. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C93256E.10103@optimsys.cz
RESULT=REJECTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 7_2: attribute enctype used with the value of the method "get" in <dialogstart> Date: July 26, 2010 3:31:15 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 7_2, assertion 371, the 'enctype' attribute is used in <dialogstart> although the value of the 'method' attribute is NOT "post" (it is "get" by default). This is related to issue 710 (http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0156.html) where we haven't received any resolution yet. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
DUP of ISSUE-710
This is not a Duplicate of ISSUE-710. The resolution in IR suite is different. For this ISSUE the resolution is to fix the test. ISSUE 710 should be rejected and spec updated to say explicitly that enctype is ignored if method is not POST. Paolo.
Resolution accepted 2010-08-23.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E8B51.9050905@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 8_2_2: invalid maxage value in <script> Date: July 26, 2010 3:47:56 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 8_2_2, script 8_2_2_A.txml contains the following <script> elements: <script maxage="'5000'" src="marker.ircgi"/> <script src="marker.ircgi" maxage="'1000'"/> According to the Specification (Section 8.2.2.2), the maxage attribute has type "Character string" and not "ECMAScript Expression". Therefore there must not be the apostrophes: <script maxage="5000" src="marker.ircgi"/> <script src="marker.ircgi" maxage="1000"/> Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution accepted: 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E8B09.5090206@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 8_2_3: how to handle error in loading static <script> Date: July 26, 2010 4:14:09 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 8_2_3, the following code is used to load a script: <script src="sleeper.ircgi" timeout="1s"/> Since the sleeper.ircgi script contains 20s delay loading of the script must fail. Our question is how to handle this loading error. The Specification, Section 8.2.2.1 contains the following note: "INFORMATIVE NOTE: The <script> element's resource loading model is a bit different than the rest of CCXML for a number of reasons. Because CCXML and ECMAScript applications can be CPU intensive to compile we define <script>'s src attribute (defining the URI of the document to load) to be a static string instead of a dynamically valued ECMAScript result. This allows implementations to load ECMAScript content at CCXML document load time and perform compiling and/or caching of the resulting ECMAScript code. We do however recognize that there are cases where a CCXML application needs to load a dynamic ECMAScript resource, for this reason applications can use the the <fetch> element to asynchronously load a resource and then execute it by referencing it's fetchid in the the <script> element." We load the script content at the CCXML document load time as recommended. The loading error results in throwing error.createccxml because we were not able to load the CCXML document or one of its parts. The CCXML document interpretation is not started at all. We believe that the test script 8_2_3_A.txml is incorrect when it expects the error.fetch event to be thrown. Please clarify on this. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution accepted 2010-09-17. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C930FED.6030708@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 9_1_B: 'error.494' event missing required attribute 'reason' Date: July 26, 2010 4:34:02 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 9_1_B, script 9_1_B.txml contains the following code: <send targettype="'ccxml'" target="session.id" name="'error.494'"/> Since the generated event doesn't contain required attribute 'reason' it is rejected and the test fails. We recommend to add the reason attribute to the event. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E3C20.3040504@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 9_2_3_B: improper error event used in <send> Date: July 26, 2010 4:59:07 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 9_2_3_B, the following code is used: <send targettype="'ccxml'" target="session.id" name="'.name_prepare_new'"/> Since the name value is invalid (starts with a dot) the <send> results in throwing an error event. The problem is that the test expects error.send.* event to be thrown. We believe that error.semantic should be thrown in this case where the attribute value is incorrect. See the Specification, Section 9.3.2 error.semantic: "This error event MUST be thrown when there is a semantic error in a CCXML element ( e.g. passing an incorrect value for an attribute, etc.)." The error.semantic is used in every situation where attribute value is incorrect so why not here? On the other hand, the only usable error.send.* event would be "general" error.send.failed (9.3.5): "This error event MUST be thrown when a <send> could not be completed for a reason not covered by another error.send.* event." Please clarify on this. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution accepted 2010-08-30. Spec change already applied. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C7B874F.1080409@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 10_5_7 and 10_5_8: invalid scripts with <join> Date: July 26, 2010 6:21:43 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In 10_5_7, script 10_5_7_A_87.ccxml is used to test parameters of the <join> element: <?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"> <var name="connid1" expr="application.connid"/> <join id2="connid1"/> </ccxml> The test assumes that the document loading fails because of the missing id1 parameter. However, the script contains so many errors (is invalid for so many reasons) that its loading can fail even if the <join> element parsing is not implemented correctly. For instance, in OptimTalk event error.createccxml contains the following reason: "tag <join> cannot be a child of tag <ccxml>". Our recommendation is to use valid script with only one invalid <join> element. The same problem appears in scripts 10_5_7_A_90.ccxml and 10_5_8_A_144.ccxml. Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution accepted: 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E8B82.1060504@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: 10_5_8: starting a dialog that is not joined to a connection or a conference Date: July 26, 2010 7:25:44 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, In, 10_5_8, script 10_5_8_A.txml contains the following elements: <dialogstart dialogid="A859_dialogid1" src="'dialog.vxml'"/> <dialogstart dialogid="A859_dialogid2" src="'dialog.vxml'"/> None of these elements joins the dialog to any connection or conference. According to the last version of the CCXML Specification <dialogstart> doesn't take connectionid from the event being processed and thus we are starting dialog that is not joined to any connection or conference. According to the specification, these dialogs must fail with an error.dialog.notstarted event generated. We recommend to modify the code as follows: <dialogstart dialogid="A859_dialogid1" src="'dialog.vxml'" connectionid=Óevent$.connectionidÓ/> <dialogstart dialogid="A859_dialogid2" src="'dialog.vxml'" connectionid=Óevent$.connectionidÓ/> Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E4082.3060608@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org>
From: Petr Kuba <kuba@optimsys.cz>
Subject: July CCXML Implementation Report: missing var in L_A.txml
Date: July 26, 2010 7:56:09 AM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
in L_A.txml, function extractCurrentDir(), variables 'i' and 'result' are not declared. The code should be:
function extractCurrentDir(currUri)
{
var i = currUri.lastIndexOf("/");
var result = currUri.substring(0,i+1);
return result;
}
Thanks,
Petr
--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@optimsys.cz
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
reopening due to e-mail comments from chris davis - forwarded to member list and attached to issue on 8/26
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C922042.6030202@iivip.com
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: July CCXML Implementation Report: L_A: eventsource in <send> Date: July 26, 2010 9:53:07 AM EDT To: www-voice <www-voice@w3.org> Hello www-voice, in L_A, script L_A.ccxml contains the following code: <send name="'name'" targettype="'basichttp'" target="session.ioprocessors['createsession']" namelist="uri eventsource foo"/> I've got the following questions regarding the eventsource attribute: 1) eventsource is required standard attribute that must be present in each event. The question is who is responsible for generating this attribute in events sent using <send>? I assume that it is responsibility of the platform to generate this attribute because otherwise it would be necessary to insert eventsource into namelist in each <send> 2) What shall happen if namelist in <send> contains some of the standard events attributes? Shall the value be replaced or shall an error event be thrown? Thanks, Petr -- Petr Kuba, Project Manager OptimSys, s.r.o kuba@optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.cz
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C932B2D.9010107@optimsys.cz
RESULT=CLARIFICATION
Resent-From: www-voice <www-voice@w3.org> From: Petr Kuba <kuba@optimsys.cz> Subject: Re: July CCXML Implementation Report: 10_2_3: missing transition for connection.disconnected - should be 10_2_4 Date: July 27, 2010 5:34:37 PM EDT To: www-voice <www-voice@w3.org> Hello, this report deals with test 10_2_4, assertion 1286. Sorry for the confusion. Petr On 26.7.2010 11:47, Petr Kuba wrote: Hello www-voice, In 10_2_3, assertion 1295 shows the following code: <transition event="user.START_ASSERTION_1286" state="ASSERTION_NMBR_1286"> <!-- 1286 10.2.4 <assign> and <var> Execution of connection elements MUST NOT immediately change the state of any associated Connection Objects mscott@voicegenie.com Accepted --> <disconnect connectionid="ConnectionID"/> <if cond="session.connections[ConnectionID].state == Connection.CONNECTED"> <script>assertions[assert_index].P_F = s_PASS;</script> </if> <send targettype="'ccxml'" target="session.id" name="name_prepare_new"/> </transition> Unfortunately there is no <transition> for connection.disconnected. If this event is delivered before the event generated by <send> the following message is logged: 10_2_4 TA-1286: Comment: UNEXPECTED EVENT connection.disconnected IN STATE ASSERTION_NMBR_1286 We recommend to handle connection.disconnected correctly to keep the test clear. Thanks, Petr
Resolution accepted: 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E8BBD.60807@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org>
From: Petr Kuba <kuba@optimsys.cz>
Subject: July CCXML Implementation Report: 7_3: unhandled conference.unjoined
Date: July 27, 2010 7:19:31 PM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
In 7_3, assert 412, the following code is used:
<transition event="connection.disconnected" state="ASSERTION_NMBR_425">
<conf:comment expr=" 'Current state : ' + current_state + ' , Event: ' + event$.name"/>
<dialogterminate dialogid="DialogID"/>
</transition>
<transition event="conference.unjoined" state="ASSERTION_NMBR_425">
<conf:comment expr=" 'Current state : ' + current_state + ' , Event: ' + event$.name"/>
</transition>
<transition event="dialog.exit" state="ASSERTION_NMBR_425">
<conf:comment expr=" 'Current state : ' + current_state + ' , Event: ' + event$.name"/>
<send targettype="'ccxml'" target="session.id" name="name_prepare_new"/>
</transition>
<dialogterminate> results in two events:
1) conference.unjoined
2) dialog.exit
The problem is that the order of these two events is not specified and if conference.unjoined is receiver after dialog.exit then it is processed by the consequent assertion. This results in unexpected event being reported.
Thanks,
Petr
--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@optimsys.cz
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz
Resolution approved on 2010-08-20. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C6E4150.6010000@optimsys.cz
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: CCXML: VoiceXML dialog.transfer.complete's result type incorrect? Date: August 16, 2010 12:38:54 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, I'm looking at http://www.w3.org/TR/2010/CR-ccxml-20100401/ section D.9 VoiceXML <transfer>/ It says that the dialog.transfer.complete should send the "results object with the value of the transfer field to be filled in" to the dialog. The CCXML example does *not* show an object for results: <var name="results" expr="'near_end_disconnect'"> Looking over at VoiceXML, it only specifies the value of the transfer field to be a string, and the example shown in CCXML is also a string(above). We recommend removing "object" from the text of dialog.transfer.complete's result description. This will keep the 3 things all consistent(VoiceXML's expectations, the CCXML wording, the CCXML example). Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Resolution accepted on 2010-08-27. Paolo
This resolution implies spec change in App D.9: - namelist, details: OLD: "results object with the value of the transfer field to be filled in" NEW: results with the value of the transfer field to be filled in" Paolo
applied to the spec on 11/11/2010. Closing the issue.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C77BBE5.5020708@iivip.com
RESULT=ACCEPTED
Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Subject: CCXML: dialog.transfer example incorrect? Date: August 16, 2010 12:46:21 PM EDT To: www-voice <www-voice@w3.org> Hello www-voice, Looking at http://www.w3.org/TR/2010/CR-ccxml-20100401/#dialogEventsDialogTransfer the dialog.transfer event has an attribute called "uri". Looking down at section "D.11 VoiceXML 2.0 Example", there is reference to "URI" (all caps) on the same event. Does that example need to be all lowercase to be consistent? Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Resolution accepted on 2010-08-27. Paolo
Missing Spec Change - D.11 OLD: "event$.URI" NEW: "event$.uri" => Several places. Paolo
applied to the spec on 11/11/2010. closing the issue.
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C77BC04.50701@iivip.com
RESULT=ACCEPTED
This was tracked as ISSUE-692 in the past. We are creating a new issue ID for this however. On Jul 26, 2010, at 7:50 AM, Petr Kuba wrote: > Hello www-voice, > > In 10_5_7, script 10_5_7_A_962.ccxml, assertion 962, the following code is used: > > <join id1="session.values.sessionOneConnID" > id2="general_connid"/> > > Since general_connid is incorrect <join> must fail. The test expects that error.conference.join should be sent in this case. > > In this case we are not sure whether error.conference.join or error.semantic event should be thrown. > > For further discussion see our previous message: > http://lists.w3.org/Archives/Public/www-voice/2010AprJun/0068.html > This was tracked as ISSUE-692 and we are still waiting for the resolution. > > Please clarify on this. > > Thanks, > Petr > > -- > Petr Kuba, Project Manager > OptimSys, s.r.o > kuba@optimsys.cz > Tel: +420 541 143 065 > Fax: +420 541 143 066 > http://www.optimsys.cz
Resolution accepted 2010-08-30. Paolo
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4C7BB7F1.9090903@optimsys.cz
RESULT=REJECTED
Resent-From: www-voice <www-voice@w3.org>
From: Chris Davis <davisc@iivip.com>
Subject: CCXML: problem with IR 8_3_B/dialog.vxml
Date: September 29, 2010 2:21:29 PM EDT
To: www-voice <www-voice@w3.org>
Hello www-voice,
Looking at the CCXML-IR test 8_3_B/dialog.vxml,
that VXML document contains a non-standard speech grammar type (text/gsl).
On their website, even Voxeo recommends to not use it:
http://docs.voxeo.com/voicexml/n2.0/frame.jsp?page=gslbasics.htm
I raise this issue because to pass the standards based CCML-IR for CCXML
you need to support non-standard things for VXML.
Does this make sense?
I'd recommend changing 8_3_B/dialog.vxml to remain standards based:
--------------------
<?xml version="1.0" encoding="UTF-8" ?>
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
<form id="Main">
<block>
<prompt timeout="200s">
This is a dialog.
</prompt>
</block>
</form>
</vxml>
-------------
I regret not being able to raise this sooner, as my earlier IR report was completed
using a simulator for the VXML dialog processor. Now my group has enough VXML
completed to run in place of the simulator and this was discovered.
Regards,
Chris
--
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Test to be fixed, resolution accepted 2010-10-07. Paolo
ACCEPTANCE=EXPLICIT,http://lists.w3.org/Archives/Public/www-voice/2010OctDec/0005.html
RESULT=ACCEPTED
Subject: CCXML: question on assertion for 7_3 #427 Resent-From: www-voice <www-voice@w3.org> From: Chris Davis <davisc@iivip.com> Date: March 16, 2011 12:43:09 PM EDT To: www-voice <www-voice@w3.org> Cc: Petr Kuba <kuba@optimsys.cz>, Paolo Baggia <paolo.baggia@loquendo.com> Hello www-voice, In assertion #427 the caller is required to hit a DTMF digit to make a VoiceXML dialog terminate its <transfer> tag. The problem is that I cannot see from the 7_3.txml how the DTMF is supposed to make it to the VoiceXML dialog. The caller is switched full duplex to a conference as part of the ASSERTION_NMBR_427 transitions. The <join> for this does not have the dtmfclamp attribute set to false, so by default his DTMF won't make it to other conference mixers. The VoiceXML dialog is receiving signal from the conference, not the caller. Because the DTMF is clamped from the caller in <transition event="conference.joined" state="ASSERTION_NMBR_427"> the VoiceXML will never receive signal. I can make our integration pass the assertion only if I change the caller's <join> to specify noclamping via: <join id1="ConnectionID" id2="ConferenceID" duplex="'full'" dtmfclamp="false"/> as part of the <transition event="conference.joined" state="ASSERTION_NMBR_427">. Does the test need changing or am I missing something? Regards, Chris -- Chris Davis Interact Incorporated R&D 512-502-9969x117
Closed per e-mail from Chris. We accepted his change.
RESULT=ACCEPTED
ACCEPTANCE=EXPLICIT,http://www.w3.org/mid/4D93308C.8060500@iivip.com