On 7/16/05, Stu Robertson <[EMAIL PROTECTED]> wrote: > Hi Rahul. It would make a nice wiki page. I'll try to put something > up over the next few days. The only reason I didn't post my test > files/scripts is because the content is clearly client-oriented. <snip/>
Sure, please take your time. Incidently, I've used JMeter [ http://jakarta.apache.org/jmeter/ ] off and on for regression testing RDCs; out of the box. > I hope the patch gets accepted to htmlunit shortly, since patching > is by far the trickiest part of what needs to be done. <snap/> Do you need help convincing them there is more than one modality to the "web" ;-? > First, we need validation that in put is an exact size, rather than > just a range, for alpha, digit and alphanum. Range works, but the > error message is goofy. The change looks straightforward, and I was > thinking of making the new attribute "size." <snip/> We should work with examples. Do you mean, for instance: <rdc:digits id="foo" size="7" /> in place of: <rdc:digits id="foo" minLength="7" maxLength="7" /> The error messages can be adjusted suitably via the config file (both instances can produce the same VUI). Or do you mean influencing the grammar itself i.e. instead of a blanket: <item repeat="1-"><ruleref uri="#digit"/></item> produce an instance specific: <item repeat="7-7"><ruleref uri="#digit"/></item> which will reduce the number of round trips (though possibly trigger more events client-side). > > The main thing though is to find or make a way to specify custom > grammars for standard RDCs. For instance, date.grxml allows year to > be optional, which for our purposes will never be the case. We'd > also like to narrow some of the grammars that accept wider input than > we need, to improve the accuracy of speech recognition. These are > generally minor tweaks, and do not change the contract between the > grammar and the RDC. <snap/> Indeed, the last line is crucial. > I see in fsm-input where these are set, and > that there's flexibility to have inline grammars and arrays of > either. <snip/> Thats the rendering bit, they're set in the respective tag file. > I didn't see a mechanism for specifying overrides for > default grammars though. I think it would be ideal if this were > doable at the per-instance level and also per-application level, the > later possibly via an init param to the grammer servlet. <snap/> At a per application level (rather per locale per app), the grammars can be set using these properties files [ http://svn.apache.org/repos/asf/jakarta/taglibs/sandbox/rdc/trunk/src/org/apache/taglibs/rdc/resources/ ]. At the per instance level, several options are available (each one will require some work): 1) Provide dynamic grammars 2) Vary validation rules suitably 3) Use RDC templates > Speaking of > which, though I haven't thought through all the way how to implement > this yet, I suspect we're going to bump head-on into the > GrammarServlet's dependence on the taglibs-rdc.jar. Will we have to > break this up to implement this? Maybe if it pulled grammars from > the classpath instead? <snip/> For app-specific grammars (i.e. grammars not packaged in the distro), the GrammarServlet is really not in the picture. The grammars can sit anywhere in the context (as long as its not a folder called .grammar at context root), and the properties file(s) above point correctly. > > Thanks for giving credit for my little wiki page :-) <snap/> But ofcourse! > Oh, before I forget, I really do need to send you a simple example of > the jsp forwarding problem with struts-submit. I'm now redirecting > between all struts actions so that no more than 1 JSP ever renders > within a single request. I understand this works in Tomcat, but WAS > 6.0.1 (haven't applied the 6.0.2 patch yet) the voice interpreter > errors out with prolog complaints. Recreating it is pretty simple, > and you might even hit it with the example apps. If not, I'll try to > find time to create a simple example, or maybe just send you > something offline. <snip/> I'll try to recreate at my end when I get a chance. Thanks, -Rahul
