RE: Timeout property or timeout attribute?

Harbanu

I don't see how to interpret 4.1.7 of the spec any other way:
The timeout attribute specifies the interval of silence allowed while
waiting for user input after the end of the last prompt. If this interval is
exceeded, the platform will throw a noinput event. This attribute defaults
to the value specified by the timeout property (see Section 6.3.4) at the
time the prompt is queued. In other words, each prompt has its own timeout
value.

This even stresses that the default is specified by the timeout property at
the time the prompt is queued. It is hard to see how the property at the
time the prompt is queued could be important enough to stress with any other
interpretation. I suppose you could say that there should be a 3s timeout in
the following example because there is no timeout property in the field, but
it would be very odd that the field's behaviour would be changed by setting
the timeout property in the field to the value it already defaults to.

<property name="timeout" value="1s"/>

<form>

   <property name="timeout" value="3s"/>

   <block>

     <prompt>some prompt</prompt>

     <goto next="#form2"/>

   <block>

</form>

<form id="form2">

   <field name="forcePlay" type="boolean">

    <!-- commented out <property name="timeout" value="1s"/> -->

     <catch event="noinput nomatch">

       <assign name="forcePlay" expr="true"/>

     </catch>

   </field>

</form>

Also section 6.3 says:

In some cases, <property> elements specify default values for element
attributes, such as timeout or bargein.

Obviously the spec is clear that the timeout property sets the default
timeout attribute and as far as I can see there is nothing in the spec
itself to suggest that the timeout property has any other semantics.

On the other hand, if the timeout is ultimately specified by the prompt
attribute, then it does raise the question of what timeout to apply if there
are no prompts, which seems to be the case with the implementation report
test case. Given that there are conflicting implementations, I don't know
how they all passed that test case. If I had to, I would guess that they add
an additional semantic that inserts an empty prompt from the <field> context
if the prompt queue is empty, thus inadvertently passing the test case.

NB if it were up to me I would change this. When designing and implementing
UIs I associate timeouts with the user not the individual prompts, so this
is a possible source of bugs. Hence I have a rule that always inserts an
empty prompt in a field if it has no other prompts.



Robert





  -----Original Message-----
  From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On Behalf
Of harbhanu
  Sent: 22 September 2006 11:57
  To: robert.keiller@voxsurf.com; www-voice@w3.org; 'Dan Evans'
  Subject: RE: Timeout property or timeout attribute?


     Hi Robert,

     I have certain doubt on the clarifications given .



      >>"The timeout property simply defines the default value of the prompt
timeout attribute. "

  The prompt just offers another alternative to update the timeout for wait
during current input collection, which can supersede the value defined by
timeout property in the scope.

  The timeout property will always apply to the recognition process even in
case there are no prompts, or prompts without timeout attribute.



  >> It is an error (albeit a common one) to believe that the timeout
property defined in a field applies to the behaviour of

  the field itself rather than to any prompts, if defined, within that
field.

  It applies to both ..;)



  Section: 6.3.4 (Prompt and Collect Properties) - (VoiceXML2.0 spec)

  Timeout : The time after which a noinput event is thrown by the platform.
The value is a Time Designation (see Section 6.5). The default value is
platform-dependent. See Appendix D.



  Also, refer to the implementation report test case No: 603

  http://www.w3.org/Voice/2004/vxml-ir/603/603.txml

  How will those implementation which always depends on the prompt's timeout
attribute will pass this testcase??



  Regards,

  Harbhanu






****************************************************************************
****************************************************************************
****************************************************************************
**********

              This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose address
is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!


----------------------------------------------------------------------------
--

  From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf
Of Robert Keiller
  Sent: Friday, September 22, 2006 2:16 PM
  To: harbhanu@huawei.com; www-voice@w3.org; 'Dan Evans'
  Subject: RE: Timeout property or timeout attribute?



  Hi,



  There certainly are or were differences in implementation for this between
different VoiceXML implementations.

  I have worked with two or three that would give a 1s timeout and I know
another implementation that would

  give a 7s timeout. Although I was initially very surprised by the 7s
interpretation, being already familiar with

  the 1s interpretation, I believe now that it is correct.



  The timeout property simply defines the default value of the prompt
timeout attribute.

  Since there is no prompt in the field itself the timeout property of 1s is
irrelevant. The only prompt

  is in the block where the default value of the timeout attribute is set by
the root document property to 7s.



  It is an error (albeit a common one) to believe that the timeout property
defined in a field applies to the behaviour of

  the field itself rather than to any prompts, if defined, within that
field.



  You can obviously fix this by putting a timeout attribute on the <block>'s
prompt. If there are implementational reasons

  why this is not possible (eg the application element that creates the
prompt does not have access to the timeout) an ugly fix

  is to put an empty prompt in the field.



  Robert







   -----Original Message-----
  From: www-voice-request@w3.org [mailto:www-voice-request@w3.org]On Behalf
Of harbhanu
  Sent: 22 September 2006 06:50
  To: www-voice@w3.org; 'Dan Evans'
  Subject: RE: Timeout property or timeout attribute?

    Hi,

    I think as per the VoiceXML 2.0 specification also, the value for
timeout must be 1s.



    Excerpts from the spec.



    Section 4.1.7 (Prompt element)

    The timeout attribute specifies the interval of silence allowed while
waiting for user input after the end of the last prompt. If this interval is
exceeded, the platform will throw a noinput event. >>"This attribute
defaults to the value specified by the timeout property"<<



    Section 6.3 (Property element)

    Properties may be defined for the whole application, for the whole
document at the <vxml> level, for a particular dialog at the <form> or
<menu> level, or for a particular form item. >>>"Properties apply to their
parent element and all the descendants of the parent."<<< A property at a
lower level overrides a property at a higher level. When different values
for a property are specified at the same level, the last one in document
order applies. Properties specified in the application root document provide
default values for properties in every document in the application;
properties specified in an individual document override property values
specified in the application root document.



    From the above two highlighted text, it is expected that the field
'forcePlay' will wait for 1sec before throwing the noinput event.



    Please let me know about your inputs on this.



    Regards,

    Harbhanu



    Ps;>Please ignore the text that follows.


****************************************************************************
***********



                This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose address
is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!



    -----Original Message-----
    From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Dan Evans
    Sent: Thursday, September 21, 2006 8:36 PM
    To: www-voice@w3.org
    Subject: Timeout property or timeout attribute?





    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