W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2006

Re: Suggested change to <audio/>

From: Shane Smith <safarishane@gmail.com>
Date: Thu, 27 Apr 2006 14:37:30 -0500
Message-ID: <8fc15e140604271237o34e8611em6e9084432c8e51aa@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:02 GMT