Menu
▾
▴
#18 Catch no-match in OpenVXML
This is related to Ticket #1. If there is a no-match produced by the ASR in Cairo, an empty string gets propagated all the way into JVXML, and an empty strings is seemingly posted back to OpenVXML. To tell a no-match from an in-grammar hypothesis, GGS will have to catch this situation and assign it a proper semantic class (such as "no-match").
To resolve this issue, I made slight changes to both Cairo and JVoiceXML code (please see Ticket #1 for details) so that obtaining a NULL (or no-match) recognition hypothesis does not cause Cairo/JVXML to crash; instead, it returns an empty string, which is then captured by a script within the OpenVXML app so that designers have a choice of what to do when such a situation is encountered.
Did you change GGS to reflect these changes?
"To resolve this issue, I made slight changes to both Cairo and JVoiceXML code (please see Ticket #1 for details) so that obtaining a NULL (or no-match) recognition hypothesis does not cause Cairo/JVXML to crash; instead, it returns an empty string, which is then captured by a script within the OpenVXML app so that designers have a choice of what to do when such a situation is encountered."
This is broken again. In order to be able to demo the system, I had to introduce a very dirty hack. In
/home/tjr/halef-cairo/cairo-VM/src/cairo/cairo-server/trunk/src/main/java/org/speechforge/cairo/server/recog/MrcpRecogChannel.java
I replaced
CompletionCause completionCause = new CompletionCause((short) 1, "no-match");
by
CompletionCause completionCause = new CompletionCause((short) 0, "success");
and return the recognition hypothesis "null" to JVXML. The no-match (and confidence value) behavior of Halef need a thorough revamp at some point.
Properly fixed this by modifying the cairo-client code used by JVXML. It now does handle the no-match completion cause and sets the RecognitionResult to an empty string.