W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2005

RE: Please redefine foreach element as it is in VoiceXML 2.1 CR

From: <ken.waln@edify.com>
Date: Thu, 16 Jun 2005 18:59:16 -0700
Message-ID: <5076FACEDACF624B965A87041DD1F9CA112509@x2.edify.com>
To: www-voice@w3.org
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 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">

            <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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:01 GMT