Please redefine foreach element as it is in VoiceXML 2.1 CR

Hi ! 
Please allow <foreach/> only in places where you can use executable content.
As executable content it is logigally easy, inside prompt not.
I try not to be rude but allowing <foreach/> in prompts will cause a very
chaotic code indeed. This one again moves voicexml more into application
logic direction and I see that this has been the motivation behind allowing
<foreach/> inside prompt element. Yes, I see the it is neat to get dynamic
prompts but you have to build the grammar anyway why you wont build the
prompts or choices too. And since you cannot use foreach for <choice/> or
<option/> elements. 
I try to bring here few problems up in here, someone could answer how this
should behave and how it makes voicexml more flexible and convenient,easy
write language for Voice UIs. IMHO enumeration was powerful enough to
iterate inside prompts, you don't need <foreach> in TUI login you need it in
application logic.What VoiceXML is for defining Application or UIs for
applications ? 
Case 1: Prompt inside prompt, how these should be queued. (how many layers
of <foreach>s we can add here?) , prompt is not allowed inside prompt. so
copy to top leave is not an option. By specification I don't know how this
is queued.. According to executable content rules.. I guess that the output
is 'somewhat twisted prompt played '.. Interesting isnt it.
        <field name="x" type="digits">
                <foreach ..>
                    <prompt> somewhat </prompt>
                    <if cond="true">
                    </if>                    i
Case 2: Executable content inside prompt and foreach, this allows a really
weird.voicexml written.. and when is this for each unwrapped.. in time of
queuing?  and when goto is executed ? when prompting comes into the state
when goto is next element ?
        <menu id="x">
                <foreach ..>
                    <goto next="#y"/>                    

And of course  the mixtures of all of these..
Best Regards.
- Teemu

Received on Wednesday, 15 June 2005 12:03:23 UTC