jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Warner" <mitch.war...@fluencyvoice.com>
Subject RE: RDC: grammar tags in the state component
Date Thu, 24 Feb 2005 11:31:34 GMT

Without worrying too much about the i18n aspect right now, initially you
should maybe just focus on allowing people to define their own phrases
for this grammar as Daniel pointed out. So rather than having a grammar
which is hard-coded to accept 'default' or 'initial', it could be
configured to accept 'my home state' or other such semantically
equivalent phrases.

It would seem that the best apprach maybe to allow people to override
the in-built initial grammar with another grammar file defined somewhere
in the system

You mentioned in a pervious mail the following two issues:

>> a) How will configuring the initial grammar per RDC instance affect
the usability of the application? 
>> Before, we had a consistent Voice User Interface (VUI) for refering
to the initial values.

Leaving aside the i18n issue, in some applications and components it may
not make sense for the user to say 'default' or 'initial'. The example I
gave above was that you may want to allow the user to say 'my home
state' or 'the state where I live'. Additionally, the 'default' and
'initial' words may be phonetically similar to other words in the main
grammar, which will reduce the accuracy of the recognition.

>> b) If we point to a "bad" initial grammar, the rendered VoiceXML page
will fail.

That is true, but then you would expect the developer to be able to
identify this fault and fix it. Perhaps you may want to consider
checking that the grammar is well-formed and valid prior to the creation
of the Vxml


-----Original Message-----
From: Rahul P Akolkar [mailto:akolkar@us.ibm.com] 
Sent: 23 February 2005 16:42
To: Tag Libraries Developers List
Subject: RE: RDC: grammar tags in the state component

 > I'm not a VUI expert, but the idea of having this
> initial grammar seems like a fine idea.  I'd think the biggest issue 
> is providing enough flexibility so that people can customize it. It's 
> inevitable that users are going to want to have control over this.  If

> for nothing else, localization; but also for changing the utterances 
> that can be used and also doing regional tuning.

Very true. Looking at the RDC tag library from an i18n perspective, let
me identify the resources that are locale specific, and the action
1) Prompts - Since we already have the mechanism (and necessary
separation) for specifying the prompts associated with any RDC instance
in terms of a config file, localizing the prompts is simply providing an
appropriate config.
2) Grammars - The component grammars defined in the tag files which are
static URI references need to be updated with locale specific URIs read
out of resource bundles.
3) Loose ends - Embedded grammars and error messages. I think the only
instance of an embedded grammar is the initial grammar, though I'll
double check. Error messages produced in the org.apache.taglibs.rdc.dm
package need to change similar to (2).

I will begin to work on the i18n, starting with (2), then (3). I'll set
things up so the grammar URIs are locale specific, but I lack the
ability to translate ;-) We will need volunteers to do the actual

> As a follow up question, do you mind pointing me to the location 
> within the code that generates this dynamic grammar?


As per discussion above, it won't stay there for long.

Can you also let me know what fails with the Nuance engine? Does it
require an xmlns attribute on the embedded grammar? I think I noticed
that with the Cisco browser. At some point, we will have a build switch,
so these "platform adaptations" can be done by specifying the platform
as a build property. Also, do let me know if you are aware of a good
compilation of platform "quirks" for various platforms. That will be a
good starting point for this exercise.


This email has been scanned for all viruses by Netscalibur Mail Scanner, powered by MessageLabs.
For more information on a proactive email security service working around the clock, around
the globe, visit

To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

View raw message