- From: Andrew Hunt <andrew.hunt@holly.com.au>
- Date: Thu, 17 Aug 2006 22:02:49 -0700
- 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 UTC