W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2003

RE: VoiceXML 2.0: Official Response #12 to Candidate Recommendation Issues

From: McGlashan, Scott <scott.mcglashan@hp.com>
Date: Thu, 20 Nov 2003 18:18:10 +0100
Message-ID: <77DB1374F763FB489900AA600DA37AE1035635A2@frqexc01.emea.cpqcorp.net>
To: "Pavel Cenek" <xcenek@informatics.muni.cz>
Cc: <www-voice@w3.org>

Hi Pavel,

Thank you very much for your timely response - we definitely appreciate
your input. 

I'm copying this to the www-voice@w3.org public list for administative
tracking of responses.

Thanks again,


-----Original Message-----
From: Pavel Cenek [mailto:xcenek@informatics.muni.cz] 
Sent: 20 November 2003 07:31
To: McGlashan, Scott
Subject: Re: VoiceXML 2.0: Official Response #12 to Candidate
Recommendation Issues

> Issue CR19-1
> 1. What did you say?
> --------------------
> In a real dialog in a noisy environment or when a user is not 
> concentrated, it can happen that a user does not understand properly a

> system prompt and wants the system to repeat it. The last prompt 
> should be repeated without increasing the prompt counter in order to 
> repeat really the same prompt. It is not possible to do it in the 
> current version of VoiceXML.
> I suggest the following solution: Add an atribute to the <reprompt> 
> tag, which allows to repeat prompts without increasing the prompt 
> counter.
> CR19-1 Resolution: rejected
> This will be considered for a future version of the language.

I am satisfied with the resolution.

> Issue CR19-2
> 2. detection and handling of multiple fills of one slot
> -------------------------------------------------------
> VoiceXML provides no means for detection and handling the situation 
> when a slot value is re-specified.
> In real conversation it can happen that a participant specifies a 
> piece of information twice with different value. The normal reaction 
> is that the other participant detects this situation and asks the 
> first one for a clarification. VoiceXML has no means for doing this.
> I suggest the following solution: Define a standard event, e.g. 
> slotredefinition.slotname that would be thrown in such a case and the 
> old value would be contained in the _message variable in the <catch> 
> tag's anonymous scope.
> CR19-2 Resolution: rejected
> This can be done within current specification by storing the values 
> and when new input is received, comparing the stored values with the 
> latest values. A future version of the language may provide a more 
> flexible approach along the lines you suggest.

I am satisfied with the resolution.

Best Regards

    Pavel Cenek


  Pavel Cenek   Ph.D. student         email: xcenek@fi.muni.cz
  Laboratory of Speech and Dialogue   www: http://www.fi.muni.cz/~xcenek
  Faculty of Informatics, MU Brno     lab page:
Received on Thursday, 20 November 2003 12:18:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:37 UTC