Re: Suggested change to <audio/>

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