Re: [vtp-dev] Problem with PlayPrompt before OptionSet

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

Brendan -

    That section is very cloudy and I can definitely see how it can be read
that way.  The part that strikes me in this situation is the 3rd example of
that section.  The key differentiator between #2 (what I think you are
describing) and #3 is that the block in the initial document with the
(unspecified) goto or submit does not declare the use of a fetch audio
resource.  If I'm reading this correctly, if no fetch audio is assigned then
the prompts in page 1 are merely queued and not played until the field is
loaded and the interpreter enters the waiting state.

    The one place that the behavior seems to be completely undefined (at
least to the specification) is when you run into a series of prompts that
transition between barge in enabled and disabled.  All vxml is assumed to
not declare a fetch audio resource so as to invoke example 3 behavior:

Page 1. Form->Block->Prompt (barge=true)
Page 2. Form->Block->Prompt (barge=false)
Page 3. Form->Block->Prompt (barge=true)
        Form->Field

    In this example it would appear the semantics of the situation calls for
both #2 & #3.  If I were King (as I am not on the interpreter side), I would
follow #3 while faking #2 behavior for page 2.  I would traverse the page
set until reaching a page that included a waiting item.  Activate any
grammars and then begin playing P1.  Upon reaching P2, I would either
deactivate the grammars or just ignore events until P2 finishes and then
return to an active listening state by re-activating the grammars or allow
events again.

    I wouldn't be opposed to adding a prompt slot to our built-in option set
widget to enable our working together more easily.  I'll throw it on the
list of items to do.  We actually supported this feature in the 2.0 version
but moved away from it because of the ability to brand the options in a menu
with not just audio but the order and even which options exist for a given
brand.  In many situations, the single audio file for the menu didn't work
for user leveraging brands.

    Please keep the feedback coming.  There are a lot of other things we can
do to more tightly support SPOT as well with our platform abstraction layer.
If there are any <object> tags or other extensions you'd like to see added
to the widget list send us the docs for them and we'll see what we can do.

Trip Gilman


On 10/28/08 10:17 AM, "Brendan Sterne" <SterneB@xxxxxxxxx> wrote:

> Trip,
> 
> Thanks for your response.
> 
> We are using our browser (Interact Inc, SPOT VoiceXML browser), which was
> written from scratch.  I think the behavior you outline is common to the
> OpenVXI-based browsers (but I could be wrong here), so this will work with
> them. But our reading of the spec, and our implementation won't support
> this.  Not a big deal as the workaround is to place the prompt into the
> 'OptionSet' node as the prompt for one of the options.  What I would like
> to see, if possible, is a field in the OptionSet config page for an
> OptionSet level prompt. Right now all we can do is assign prompts for each
> option.  The would be cleaner for us.  Implementationally it shouldn't be
> too complicated.  I would be happy to try and contribute this myself,
> though it'll take a little bit to learn my way around the codebase.
> 
> Your thoughts?
> 
> Cheers,
> - Brendan
> 
> --
> Brendan Sterne
> Interact Inc Austin R&D
> sterneb@xxxxxxxxx
> 
> 
> -----Original Message-----
> From: Trip Gilman <trip@xxxxxxxxxxxxxxx>
> To: Vtp-Dev <vtp-dev@xxxxxxxxxxx>
> Date: Tue, 28 Oct 2008 10:05:32 -0500
> Subject: Re: [vtp-dev] Problem with PlayPrompt before OptionSet
> 
>> This is true.  However, a voice browser typically reads ahead in the
>> application until it reaches a waiting state (field, menu, record)
>> before
>> beginning to execute that section of the application.  You can think of
>> an
>> application broken into segments each consisting of a virtual turn that
>> can
>> span multiple pages:
>> 
>> ----Turn 1-----
>> Page 1. Form->Block->Prompt
>> Page 2. Form->Block->Prompt
>>         Form->Block2->Prompt
>> Page 3. Menu
>> ----Turn 1 End----
>> 
>> ----Turn 2----
>> Page 4. Form->Block->Prompt
>>         Form->Field
>> ----Turn 2 End----
>> 
>> In the example, the first 3 pages are read before the prompt on page 1
>> is
>> played.  Each prompt is queued up and the system begins listening for
>> Menu
>> input.  Voice bargeins are available as there are no "page transitions"
>> while the prompts are playing.  This of course is an over
>> simplification of
>> the process but it outlines the general process.  Not all platforms
>> operate
>> in this way but it is rather common to see.
>> 
>> What voice browser are you using with loquendo?
>> 
>> Trip Gilman
> 
> 
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev