RE: VXML 2.0 "expr" attribute of <audio>

Ian,

Here is my change suggestion to the VXML 2.0 W3C Working Draft specifications from 24 April 2002 section "4.1.3 Audio Prompting" to address the problem you raised concerning the evaluation of the audio expr attribute.

"expr:     An ECMAScript expression which controls the audio to play. If the expression resolves to a ECMAScript platform-dependent host object representing a previously recorded audio value, then the recorded audio is played. Otherwise, if the expression can resolve to an ECMAScript string then it is interpreted as the URI to fetch (if the URI happens to be malformed then an error.badfetch event is thrown. If the expression resolves to the ECMAScript undefined value, then the audio element is ignored. In other cases, an error.semantic event is thrown."

I think this suggestion provides the following answers to your questions:

> What are the exact rules for when the value of an <audio>'s "expr" is
> treated as a dynamically determined URL, and when it's treated as
> recorded audio?  What if, for example, "expr" has a value that's a
> function call output?  

As suggested above, depending on the runtime type of the resolved expression it is turned into either a URI or the value of a prerecorded audio.

> Is it possible to "construct" recorded audio
> using ECMAScript functions, and if so, would this be played?

Yes, just provide the unquoted name of the form item variable holding the recorded audio ECMAScript host object.

>  What if you have some other form input variable as the value of "expr", but
> it wasn't filled in with recorded audio?  

If this can be resolved into a URI, then the corresponding audio is fetched, otherwise either an error.badfetch or error.semantic event is thrown depending on the runtime type of the ECMAScript expression.

> Will <audio> try to play it or
> treat is as a URL?  

If this is text such as "coke", it would try to parse it as an URI, would fail to do so and would consequently throw an error.badfetch event. It would never try to interpret is a speech output. This is reserved for the value element which can not be used to playback recorded audio (see Appendix J —Changes from VoiceXML 1.0 "Removed capability of <value> to playback a record. Only <audio> can be used to playback recording (2.3.6, 4.1.3, 4.1.4)")

> I hope the way a value is treated is not dependent
> on the syntactic form of the "expr" value.

I hope this feedback can help, any comment is welcome.

Regards,

Guillaume. 

> -----Message d'origine-----
> De : www-voice-request@w3.org [mailto:www-voice-request@w3.org]De la
> part de Ian Sutherland
> Envoyé : jeudi 22 août 2002 21:23
> À : www-voice@w3.org
> Objet : VXML 2.0 "expr" attribute of <audio>
> 
> 
> 
> The latest publically available version of the VXML 2.0 Working
> Draft describes the "expr" attribute of <audio> as
> 
>  Dynamically determine the URI to fetch by evaluating this
>  ECMAScript expression.
> 
> However, multiple examples in the text of the draft (including one
> right at the start of 4.1.3) seem to indicate that if "expr" is a
> variable containing recorded audio, the recorded audio is supposed
> to be played at the point where the <audio> tag is, rather than trying
> to treat the recorded audio as a (no doubt ill-formed) URL.
> 
> What are the exact rules for when the value of an <audio>'s "expr" is
> treated as a dynamically determined URL, and when it's treated as
> recorded audio?  What if, for example, "expr" has a value that's a
> function call output?  Is it possible to "construct" recorded audio
> using ECMAScript functions, and if so, would this be played?  What if
> you have some other form input variable as the value of "expr", but
> it wasn't filled in with recorded audio?  Will <audio> try to play it or
> treat is as a URL?  I hope the way a value is treated is not dependent
> on the syntactic form of the "expr" value.
> 
> -- 
> Ian Sutherland
> 
> Voice Laboratory                    E-mail: ian.sutherland@oracle.com
> Oracle Corporation                  Work:   312-704-4723
> 45th Floor, Sears Tower
> 233 S. Wacker Drive
> Chicago, IL  60606  USA
>

Received on Tuesday, 3 September 2002 08:19:28 UTC