It has been more than a year since we adopted JVXML into Halef. A lot of changes have happened since in JVXML spearheaded by Dirk (Schnelle-Walka), and some changes on Halef's front, too. @Vikram, would you please coordinate an ongoing synchronization effort with Dirk to get both of these repositories in sync? Would it be worthwhile to add Dirk as active developer to the Halef project, too?
Hello Dirk,
I still haven't finished working my way through the JVXML how-to-build guide, so I'll continue to work on that as I find time. That said, I'm happy to help with the development in any way I can, given my current stage of proficiency with JVXML.
I see the main challenges in
Other minor issues may appear when we have accomplished that.
The current implementation in the Halef repository is a workaround that
will work only with the setup at ETS. Other settings, espacially builtin
grammars and inline grammars will not work with that implementation.
I see.
Therefore, a main issue will be to change the implementation of
org.jvoicexml.interpreter.ActiveGrammarSet to manage a set of URIs
rather than GrammarDocuments. These grammars will be activated or
deactivated as needed with the SpokenInput implementation.
SpokenInput will get a method to load grammars by an URI, as it is the
case in the Halef repository.
I see that SpokenInput can get as input a list of supported grammar types. So is the intention to specify the grammar type (and corresponding URI) in this class?
The DocumentServer will have another method addDocument():URI to store
such generated grammar documents and retrieve an URI that will be part
of the ActiveGrammarSet. A new DocumentStorage component at the document
server will take care to manage these mappings of externally accessible
URIs and documents. I think that I will embed jetty for that.
Is it the case that JVXML (the original) does not have native support for external grammars?
The SpokenInput implementations will have to be adapted to work with
URIs rather than a Reader to load the grammars. This is already the case
for the Halef MRCP platform but will have to be changed for all other
implementation platforms.
So is this something that only needs to be modified in the JVXML codebase, mainly, before pulling into HALEF?
I suspect that this can be a basis for Halef to use the JVoiceXML
repository.
Afterwards, I will have to add a similar behavior for the SSML documents
that I generate while executing a voice browser session. They will be
accessible by URIs as well. This may require some changes in the Halef
implementation, maybe also with the MRCP layer.
I believe that our current SSML support integration is not completely there anyway; so this might be something to work on.
Any help with the implementation is appreciated. I already started with
some interface concepts at the document server.
Again, I'm happy to help -- I'll try and get up to speed with this as soon as I can.
Regards,
Vikram