- 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