- From: <ken.waln@edify.com>
- Date: Thu, 16 Jun 2005 18:59:16 -0700
- To: www-voice@w3.org
- Message-ID: <5076FACEDACF624B965A87041DD1F9CA112509@x2.edify.com>
No one has responded, but this is an interesting comment. Perhaps the wording of the document needs to make clear what is shown in the examples but not leave everything so open. Specifically <foreach/> when used in a prompt element can only contain elements which are allowed as children of <prompt/> (<audio>, etc.) and if used in an executable context can only contain children which are valid in an executable context. That avoids these counter examples but allows the examples in the spec. Too bad no one (me included) noticed this in the working draft, but the current wording does leave open-ended what are valid child elements so it becomes a kludgey way to put executable content in a non-executable context. I don't think the <foreach> extension was envisioned as being a way to nest prompts or mix up the executable and non-executable contexts. Ken _____ From: Teemu.Tingander@tecnomen.com [mailto:Teemu.Tingander@tecnomen.com] Sent: Wednesday, June 15, 2005 5:03 AM To: www-voice@w3.org Cc: jim@larson-tech.com Subject: 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 UI´s. 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 UI´s 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 isn´t it. <field name="x" type="digits"> <prompt> prompt <foreach ..> <prompt> somewhat </prompt> <if cond="true"> <prompt>twisted</prompt> </if> i </foreach> played </prompt> 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"> <prompt> Hello <foreach ..> <goto next="#y"/> </foreach> World </prompt> ... </menu> And of course the mixtures of all of these.. Best Regards. - Teemu
Received on Friday, 17 June 2005 01:58:16 UTC