- From: Shane Smith <safarishane@gmail.com>
- Date: Thu, 27 Apr 2006 14:37:30 -0500
- To: "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: www-voice@w3.org
Al, Thanks for the suggestions, the easy way around this for me is to just crank the value for content expiration in production. The drawback is small enough not to be a huge bother (keeping the directory pointing to the audio as a variable, which is good practice anyway) if you thought that last idea was "out there" I'll raise the ante.... <prompt> and <audio> have completely mutually exclusive attributes: Prompt: bargein, bargeintype, cond, count, timeout, xml:lang, xml:base. Audio: fetchtimeout, fetchint, maxage, maxstale, expr, src Both due nearly the same thing, one mainly for audio and one mainly to control how prompting works with the fia. (ha, you thought I was going to say tts, didn't you) Well, audio already does tts as a backup, but you'd have to fake a bad url to use it for tts all the time. Anyone see where I'm going with this? Two words: One tag. Combine them. <audioprompt/> Give it both sets of attributes, the nesting ability I spoke of before, and the backup capability we already have. Really, why have two? (yea, I'm sure some of you know why, but hey, I like my idea. Sure, the 'count' and 'timeout' attributes from prompt could be confusing if nested, someone smarter than me can figure a way around that. ) Backwards compatiblility could be easily accomplished by the vendors by just calling the new audioprompt tag with the set of attributes listed by either prompt or audio in older code. I don't even think nesting would affect that. Older code wouldn't have a prompt nested in a prompt, and audio is a valid child of itself already anyhow. (in case a wav file is the backup of a wav file) Should be totally backwards compatible to conforming browsers. Thanks, Shane Smith On 4/27/06, Al Gilman <Alfred.S.Gilman@ieee.org> wrote: > > At 11:37 AM -0500 4/27/06, Shane Smith wrote: > >Hey Folks, > > > >One of the best features of audio is the ability to play backup tts > >should the audio source be unavailable. Currently though, <audio/> > >requires either the src or expr attributes to be listed, or a badfetch > >is tossed. Well, I've come upon a scenario where I wouldn't > >necessarily want to list either, and use the backup tts feature in a > >way that wasn't anticipated, but could be very useful. > > > >For example, let's say I'm playing an account number to the caller: > > <audio expr="AudioDirectory+'1.wav'">1</audio> > > <audio expr="AudioDirectory+'2.wav'">2</audio> > > <audio expr="AudioDirectory+'3.wav'">3</audio> > > <audio expr="AudioDirectory+'4.wav'">4</audio> > > <audio expr="AudioDirectory+'5.wav'">5</audio> > > <audio expr="AudioDirectory+'6.wav'">6</audio> > > > >I'm not going to prerecord every possible number, so I play audio one > >digit at a time. But, if for any reason one or more of them is > >unavailable, I would rather the whole thing be read back as TTS. The > >above code sounds horrible as backup tts, and I do not really have > >ssml control over it. > > > >What I would like to see is this: > > > ><audio> > > <audio expr="AudioDirectory+'1.wav'/> > > <audio expr="AudioDirectory+'2.wav'/> > > <audio expr="AudioDirectory+'3.wav'/> > > <audio expr="AudioDirectory+'4.wav'/> > > <audio expr="AudioDirectory+'5.wav'/> > > <audio expr="AudioDirectory+'6.wav'/> > > <prosody rate="-10%"> > > <say-as interpret-as="digits">123456</say-as> > > </prosody> > ></audio> > > > >This (or something similar) would allow you to chain a bunch of audio > >prompts together, but if any of them fail, have a single backup tts > >prompt replaced for all of them. In my head, if all numbers wav files > >were unavailable, or even if just 5.wav were unavailable, none of them > >would play, and the ssml'ed TTS would play instead. > > > >Thoughts? > > Option 1: > > have you looked at using a SMIL[1] as the @src value? > > I think you would have to do things with test variables to force > it to fail atomically if any of the embedded <seq> constituents > were unavailable, but the concatenation is there. > > Option 2: > > Alternatively, review DISelect when it re-emerges in its > next incarnation [2] and consider how you would fold this into > VoiceXML 3.0. > > Option 3: > > Program the sequences-and-options logic in SCXML [3]. > You may get this in VoiceXML 3.0 even if you don't push for it. > > Al > > [1] http://www.w3.org/TR/2005/REC-SMIL2-20051213/ > > [2] (some version dated after today of) http://www.w3.org/TR/cselection/ > > [3] http://www.w3.org/TR/2006/WD-scxml-20060124/ > > Al > > > > >Thanks, > >Shane Smith > > >
Received on Thursday, 27 April 2006 19:37:37 UTC