W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2006

<foreach>: concern about executable content

From: Andrew Hunt <andrew.hunt@holly.com.au>
Date: Thu, 17 Aug 2006 22:02:49 -0700
Message-ID: <14F99AAB26DBE04E87B64C252587948201007E0F@ehost005-2.exch005intermedia.net>
To: <www-voice@w3.org>
Cc: "David Scarratt" <dscarratt@holly.com.au>

Dear VBWG,

Here are two additional issues relating to <foreach> in the VoiceXML 2.1
CR.

[1] Arbitrary executable content within <prompt>

Around 14 months ago there was an issue regarding <foreach> raised by
Teemu Tingander including an alternate proposal.
Ref: http://lists.w3.org/Archives/Public/www-voice/2005AprJun/0064

We agree with the concern raised by Teemu that the current normative
Schema allows arbitrary executable content within a <foreach> contained
within a <prompt> and that this creates some content that is potentially
bizarre.  e.g. how should one treat a <reprompt> buried within a
<foreach> within <prompt> within a <menu> - likewise a <disconnect>,
<exit>, <return>...?

That said, we recognize that there is value in allowing <foreach> within
<prompt>.  We propose continued support for <foreach> within <prompt>
but with the following strict limitation.  We believe that this
limitation (a) permits the flexible prompting functionality implied by
the introduction of <foreach>, (b) does not restrict the full
programmatic use of <foreach> when used as executable content (i.e. not
within a <prompt> element) and (c) eliminates the side-effects of the
current Schema.

1. As per CR, maintain current <foreach> functionality when used as
executable content including when <foreach> contains prompt and/or
executable content

2. Permit <prompt> element to contain <foreach> elements with the
constraint that...

3. A <foreach> element within <prompt> may contain only normal prompt
content (strictly, "allowed within sentence" content) and may not
contain executable content.  The allowed elements are CDATA, <break>,
<value>, <emphasis>, <mark>, <phoneme>, <prosody>, <say-as>, <sub>,
<voice>, <sentence/s>, <paragraph/p>

4. A <foreach> element within a <prompt> cannot contain <prompt>
elements or executable content.

We believe that this approach is Schema-enforceable, maintains the
spirit of the <foreach> functionality, and will improve consistency of
implementation of the standard.


[2] <foreach> and implicit prompts

VoiceXML 2.0 Rec (4.1.2) allows implicit <prompts> where (a) there is no
need to specify a prompt attribute (like bargein), and (b) The prompt
consists entirely of PCDATA, <audio> and <value> elements.

Perhaps it is worth stating explicitly in 2.1 that <foreach> as <prompt>
content requires explicit <prompt> markup.  For example,

     <block>
         <foreach item="i" array="myarray">
             <audio expr="i.wav"/>
         </foreach>
     </block>

is OK, because <block> can contain <foreach> as executable content and 
the <audio> can be interpreted as <prompt><audio></prompt>, but

     <field>
         <foreach item="i" array="myarray">
             <audio expr="i.wav"/>
         </foreach>
     </field>

is not OK, because <field> can't contain executable content and 
<foreach> is not one of the elements that implies <prompt>.


BTW, could the Working Group please provide guidance on the status of
the CR and progress to PR.  I cannot find any public comment since
August 2005 on the timeline for advancing the specification.  Curious
folk would like to know. :-)

Regards,
  Andrew

---
Andrew Hunt
VP Engineering, Holly Connects
Level 11, 301 George Street, Sydney, NSW 2000, Australia
Ph: +61 2 8207 8207   Mob: +61 411 486 870
Email: andrew.hunt@holly-connects.com
Received on Friday, 18 August 2006 16:10:56 GMT

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