This provides a nice hook for all sorts of things developers might
want to do when a grammar is matched. One of the challenges we're
bumping into is that without this sort of hook, "app space" is quite
limited to functionality directly implemented in the base RDCs. This
approach is appealing because it makes adding "earcons" trivial (in
the simple case; we're using it with dynamic config files with earcon
includes), and extending RDCs with custom behaviors possible (per-
instance client-side validation for instance...or again generalized
in app-space through config file includes, as we intend).
Anyway, since it's optional and adds needed flexibility it at least
fits the general description of things that are nice to support in a
framework like RDCs. We've bounced around different approaches, and
this one seems interesting to us. We're very interested in input.
Stu
On Aug 3, 2005, at 5:58 PM, Shane Smith wrote:
Folks,
I'd like to suggest the following addition to RDC's and see what is
thought of it. In many cases, voice applications will have to perform
some sort of client side code prior to submitting back to the server.
Yes, I realize that the whole idea is to keep logic on the server
side, and this isn't specifically breaking that rule.
For exmaple:
The echo attribute in many of the rdc's will help confirm for the
caller their selection. The problem is that it requires a round trip
to the server to happen. My requirement is currently that an audio
cue be played when a grammar is matched. Normally, this round trip
wouldn't be a problem, but... I use fetchaudio, fetchaudiodelay, and
fetchaudiominimum attributes of vxml. I need an audio cue to be
played prior to any fetching audio, as even if the http round trip
takes 50ms, I'm cued up to play a full 2 seconds of audio. Now I
could programatically turn this property off and on, but I think I
have a more elegant solution, that will also appeal to a wider
audiance.
In fsm-input.tag, I have the following code:
<filled>
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/filled-pre-submit-list/*"/>
<c:if test="${!model.skipSubmit}">
<script src="${pageContext.request.contextPath}/.grammar/
nbest.js"/>
<var name="${model.id}ResultNBest" expr="serializeNBest()"/>
<submit next="${model.submit}" method="post"
namelist="${model.id}ResultNBest"/>
</c:if>
</filled>
The addition is:
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/filled-pre-submit-list/*"/>
By locating this inside the filled, but before the submit, I can code
vxml in the config file for output at runtime. Here is a snippet from
my config:
<filled-pre-submit-list>
<prompt bargein="false">
<audio src="selection-made.vox"/>
</prompt>
</filled-pre-submit-list>*"/>
But, I'm not limited with prompts! Look at the xpath locator portion.
Other rdc:get-configuration's specifically look for a certian child,
for example:
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/help-list/help"/>
I'm actually prevented from using anything but <help> inside my
<help-list>. Now, while this is usually the case, I think we still
ought to let a developer add something else in if they want to.
<rdc:get-configuration xml="${model.configuration}"
locator="/config/${stateNode}/help-list/*"/>
It's a requirement with the <filled-pre-submit-list> though, as I may
want to set a variable, run javascript, play an audio file or <prompt
bargein="false">OK got it</prompt> prompt. Actually, the full list of
possibilities is:
<assign> <audio> <clear> <disconnect> <enumerate> <exit> <goto> <if>
<log> <prompt> <reprompt> <return> <script> <submit> <throw> <value>
<var>
All are valid children of <filled>. Yes, the developer now has the
opportunity to break the 'style' of RDC's (prompt, get input, go back
to the server) but also allows for much more robust applications, such
as a simple audio cue signaling I've heard something. When you mix
this into fetchaudio properties, you can see why a server round-trip
for an audio prompt is unworkable.
Thanks, and thoughts?
-Shane Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
