Vani,
I have attached two mails which describes about solution to questions.
But this solution is not fully accepted by the RDC Team.
Rahul,
I think, we have to support passing "namelist" to the component
since people are finding difficulty to implement the same.
Regards
Aravilli
-----Original Message-----
From: Vani Ampavathina [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 11:24 AM
To: taglibs-user@jakarta.apache.org
Subject: Regarding RDC
Hi
I am evaluating the RDC Tag libraries to use in our speech
applications.Ihave a small difficulty in using these tags. can you
help me in briefing a
solution for the following problem.
1) When I use,say for example "alpha" tag, I would like to have my own
logic
in the "filled" block rather having the default submit and the namelist
formed from the Nbest.js. From the provided document , I understand that
we
can use the submit attribute to submit to any other JSP, but what about
the
variables i wish to pass on to the next JSP?
Say to have something like
<filled>
<submit next="UseCollectedAlpha.jsp" namelist="alphacollected var1 var2
var3"/>
</filled>
instead of
<filled>
<script src="/rdc-examples/.grammar/nbest.js"/>
<var name="alphaResultNBest" expr="serializeNBest()"/>
<submit
next="/rdc-examples/alpha.jsp;jsessionid=CD6603360BFF6C0D33417D414A2D205
C"
method="post" namelist="alphaResultNBest"/>
</filled>
is it possible to implement this? whats the reason to send the
confidence,
utterance and the interpretation as a serialized object from the
nbest.js?
by default the maxNBest is set to 5 and all the values are concatenated
and
returned. is there any special reason of such implementation, when i can
directly take up the "application.lastresult$.utterance" for the most
probable value, the asr recognized.
2) how is a simple JSP with 4 lines of code getting translated to few
tens
lines of code? The tutorials and wikis doesn't help in understanding the
concept.The only vxml tag I can see in the Tag library is <form> in "
task.tag". The config file gives the prompts list, this part is
understood. But how are the attributes like minLength and maxLength of
"alpha" tag, for example, used to limit the grammar as I notice there is
no
direct correspondence to these attributes, and where is the input
entered by
the user getting validated?
Regards
Vani
--- Begin Message ---
Rahul,
I have some issues with current RDC
1) Some Media Servers may not support the Java scripts so it is good
to provide a configuration file to generate script element or not.
Currently "fsm-input.tag" uses the following piece to generate the
script element.
<filled>
<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>
2) Most of the RDC components provides submit location to specify
<rdc:builtinGrammar id="testAb"
submit="http://host:8080/rdc/exit.do"; config="/config/test.xml />
But there is no option specify the namelist along with submit location.
In some forms struts-submit may not be required.
3) Similarly some Media Servers may not support the following
properties which are in fsm-input.tag
<property name="maxnbest" value="${model.numNBest}"/>
<property name="confidencelevel" value="${model.minConfidence}"/>
So in order to overcome the above issues, I have used the following
solution
1) Remove the property elements in fsm-input.tag
[best option would be move these properties to the config file rather
than hard coding in the fsm-input.tag and change the config schema such
that it supports one more element "property" . In this way we can
specify several property element which are supported by VoiceXML
specification and Media Servers]
2) commented the script and modified the submit
element in fsm-input.tag
<filled>
<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"/>
-->
<submit next="${model.submit}" namelist="${model.namelist}" />
</c:if>
</filled>
3) Added "namelist" property in the BaseModel.java and
modified the builtinGrammar.tag such it takes this attribute also. I
have added in the BaseModel because it can be used in other tags like
digits, date etc also.
<rdc: builtinGrammar id="testAb" submit="http://host:8080/rdc/exit.do";
config="/config/test.xml" namelist="testAbInput true" />
Please provide your views/ideas in order to achieve the same?
Regards
Aravilli
--- End Message ---
--- Begin Message ---
Aravilli -
For starters, what platform are you deploying on? Do you have a link
or pointer to the documentation for this platform? I've never used
such a stripped down platform, so it'd be good to know. Thanks. Now on
to your questions ...
On 1/11/06, Rao, Aravilli Srinivasa <[EMAIL PROTECTED]> wrote:
>
> Rahul,
>
> I have some issues with current RDC
>
<snip-descriptions/>
>
>
>
> So in order to overcome the above issues, I have used the following solution
>
> 1) Remove the property elements in fsm-input.tag [best
> option would be move these properties to the config file rather than hard
> coding in the fsm-input.tag and change the config schema such that it
> supports one more element "property" . In this way we can specify several
> property element which are supported by VoiceXML specification and Media
> Servers]
>
<snip/>
You can specify properties in the config file. You cannot, however,
suppress the ones in fsm-input.tag, thats true. See overall comments
below.
>
>
> 2) Commented the script and modified the submit element in
> fsm-input.tag
>
>
> <filled>
>
> <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"/>
>
> -->
>
> <submit next="${model.submit}" namelist="${model.namelist}" />
>
> </c:if>
>
> </filled>
>
>
> 3) Added "namelist" property in the BaseModel.java and
> modified the builtinGrammar.tag such it takes this attribute also. I have
> added in the BaseModel because it can be used in other tags like digits,
> date etc also.
>
>
> <rdc: builtinGrammar id="testAb" submit="http://host:8080/rdc/exit.do";
> config="/config/test.xml" namelist="testAbInput true" />
>
>
> Please provide your views/ideas in order to achieve the same?
>
<snap/>
So, to summarize:
These issues are observed in using a platform where the available
support is lesser than the minimum anticipated by the RDC taglib, i.e.
* There is no ECMAScript (for the casual observer, this is quite
different as compared to say, graphical browsers, where the user can
just "turn it off")
* Some VoiceXML 2.0 properties are not supported.
Now, as notes about the constraints we should work under, a couple of
"sweeping" comments -
1) We cannot break the fundamental premises in componentization.
2) We cannot break backwards compatibility (well, not drastically till
RDC 2.0 atleast)
Due to (1), it won't be prudent to have an arbitrary "namelist" on a
component and use it to return a set of values that may have nothing
to do with the internals of the component itself. However, it is quite
easy to achieve what you desire using an external VoiceXML submit tag
in your JSP, i.e. to say -
<rdc:someRDC id="myRDC" ... />
<c:if test="${not empty myRDC}">
<submit next="url/of/choice" namelist="myRDC foo bar" />
</c:if>
where foo and bar are variables unrelated to the myRDC component.
Due to (2), we cannot change the fsm-input tag unless we can
demonstrate backwards compatibility. One way to achieve that, would be
to introduce a "minimal" RDC configuration, which caters to platforms
that don't support scripting and/or any VoiceXML properties, and
direct the input state through a fsm-input-minimal tag instead, if
that configuration is chosen. The difference can then be illustrated
as:
<rdc:date id="myDate1" />
<rdc:date id="myDate2" platform="minimal" />
(or some such well thought out attribute name and values, ones used
here for illustration only)
This approach will ensure that the changes propogate across all RDCs.
So, I would approach this by:
1) Authoring a "minimal" fsm-input
2) Modifying fsm-run to branch if "minimal"
3) Not adding a namelist, since that should be handled outside the
component boundary
If you're interested in tackling this, please file an enhancement
request in Bugzilla. I am inclined to mark it to LATER (which means it
will not be applied any time in the immediate future), but it may be
helpful to others, and it'll be nice to have this issue on file as
well.
I'm inclined to mark it LATER because:
a) There are some minimal platform requirements for any project, and
those for RDCs do imply full VoiceXML 2.0 support. At some point,
trying to support every platform just becomes code bloat.
b) You're the first to ask for this support. If indeed many users ask
for this support in the future, we can revisit this if its on file.
Finally, thanks for the rdc:builtin component you've submitted via
Bugzilla. I've looked at it, and it looks good, but I need to make a
couple of changes:
I) "type" property doesn't belong in BaseModel
II) The config file you've attached is fictitious and cannot be used
I'll make the necessary changes before adding the new component,
that'll probably be a few more days.
-Rahul
>
> Regards
>
> Aravilli
>
>
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
