- From: Dan Evans <devans@invores.com>
- Date: Thu, 21 Sep 2006 11:05:39 -0400
- To: www-voice@w3.org
The following document (extracted from a larger one) produced a surprising result which seems to highlight an omission in the spec. <vxml application="root.vxml"> <property name="inputmodes" value="dtmf"/> <form> <block> <prompt>some prompt</prompt> <block> <field name="forcePlay" type="boolean"> <property name="timeout" value="1s"/> <catch event="noinput nomatch"> <assign name="forcePlay" expr="true"/> </catch> </field> </form> </vxml> root.vxml <vxml application="root.vxml"> <property name="timeout" value="7s"/> </vxml> The question is: how long does the field forcePlay wait before throwing noinput? The answer: 7 seconds. But if the field timeout property is moved to the dialog scope, the answer is: 1 second. The justification supplied by the vendor of the VoiceXML interpreter I was using was that the prompt: since it did not specify a timeout attribute, defaults to the timeout property in scope (spec 4.1.7) when the prompt is queued (the root timeout). The same section also says that the prompt timeout attribute is for supporting tapered prompts. The spec appears to be silent on the relative precedence of a prompt timeout versus an explicit property timeout for a field. I think the local scope property timeout should have precedence when there is a conflict. This would make timeout specification explicit instead of an inadvertent, and potentially unexpected, side effect. As an alternative, the prompt timeout attribute could define an empty value to allow the developer to indicate that the prompt should not carry an inherited timeout: <prompt timeout=""> or <prompt timeout="none">. Dan Evans
Received on Thursday, 21 September 2006 15:03:39 UTC