Tips for Investigation 5

• Work through or at least look at the first several pages of the tutorial. Then open up the Voice XML Reference and the Grammar Reference so that they're handy while you're working. For both, the PDF form can be a little easier to navigate, although I've seen a discrepancy between the PDF and what's online in at least one place, and the PDF was wrong.
• If you're using form structure, there are some very nice built-in grammars listed in the documentation. However, it does not appear possible to use these grammars from within other grammars via external reference (at least not from Nuance GSL or ABNF grammars).
• DO NOT use the Nuance GSL. When a Nuance GSL grammar has an error in it, the log output shows only "Grammar failed to compile". When using ABNF, however, you get a list of errors, along with line numbers and useful descriptions of the error. Unfortunately, ABNF is not a powerful as Nuance GSL, but even some of the examples straight from the grammar reference for Nuance GSL failed to complie, and the Nuance GSL's full documentation is proprietary. You're welcome to try the XML Speech Grammar or JSGF formats; I haven't tested those.
• While using ABNF, remember your semicolons. Also, although extracting data is not as easy when using ABNF, especially when not using a <form> element, you can always use application.lastresult$.interpretation to access the semantic representation generated by your grammar in Javascript.
• To achieve more freedom in design than the form structure allows, consider using universal grammars along with event handlers. Note that if you're just doing this, you'll need to have a single form that can't accept input so that the call won't just be dropped immediately.
• When throwing events, note that messageexpr seems to only be evaluated the first time the <link> tag gets executed, and then cached for future use. Instead of trying to send data to the event via message (which is accessible via the _message Javascript variable), just put the data into some other Javascript variable and access that variable in your event handler.
• All of your inline scripts and grammars should use the <![CDATA[ ... ]]> notation. It will save you from wasting time debugging strange errors.
• The W3CSchools website has good Javascript tutorials, and they provide webpages where you can mess around with Javascript and execute small pieces of it (http://www.w3schools.com/jsref/default.asp is the reference, http://www.w3schools.com/JS/tryit.asp?filename=tryjs_formattext is one of the live Javscript pages.). This is a good way to test bits of Javascript and debug them without going through the whole upload-call-view log cycle.
• When programming in Javascript, you can get detailed error information via your browser's error console. Also note that at BeVocal Cafe, all of your variables must be declared using the "var" keyword, or via xml tags.
• The debugging cycle at BeVocal Cafe is generally: 1. Update your file, save it, and upload it. In the "Tools & File Management" window, click on it, and click the "Check" button to make sure that the xml is well-formed. 2. Call the BeVocal Cafe number (use speeddial, or at least write it on a piece of paper). You can enter your PIN as soon as you hear the sound that's played before the voice starts speaking. Interact appropriately with your application, until bad behavior or an error occurs. 3. Click on "Log Browser" in the left-hand panel at BeVocal Cafe. The most recent log entry should be the call you just made. Click on it, and scroll down until you see the error in red. It should be pretty informative, and give you a good idea as to how to fix your bug (unless you're using the Nuance GSL, as mentioned above). Note that the "Refresh View" button in the log browser doesn't seem to work. Just click on "Log Browser" at the left again, or refresh the page.
• With ABNF, grammars aren't that bad to debug, but if you have to navigate around other parts of your vxml to get to the grammar you're testing, it can be a pain. To test grammars quickly, download grammartest.vxml, upload it to your account, and activate it. Then, paste the grammar or part of a grammar that you want to test into "test.gram" (or simply change the reference in grammartest.vxml, or make the <grammar> tag in that file into an inline grammar and paste your grammar there) and make your call. The grammartest.vxml vxml just consists of a single form that loops indefinitely, saying "Prompt" each time it does, and saying "Success" if the input is recognized. If you don't give input or your input doesn't match, it says so. Note that you can use the same syntax used in that file in <submit> tags to redirect from one form to another in your programs: just put '#' before the id of a form to redirect to that form. You can also tack this syntax onto the end of a URL for another vxml file to redirect to a specific form in that file.
• To simplify you grammar-building chores somewhat, and as a potentially useful reference, I've built an ABNF grammar for recognizing dates and times. It's pretty basic, so you might want to build your own, depending on your interface design, but feel free to use it as-is, use it as a reference, or alter bits of it to make your application work. The grammar file is datetime.gram, and although it doesn't come with appropriate Javascript for extracting the assigned variables as more complex constructs, that should be fairly easy to do. Note that although this code has been tested somewhat, it's possible that it contains a bug. If you see or suspect a bug, email me (pmawhorter@gmail.com).
• One note on grammars: the power of the speech recognition is largely dependent on constraints introduced by the grammar. This means that the more ambiguous your grammar, the more likely it is to make mistakes. As an example, when testing the given datetime grammar, I tried the phrase "thirty minutes 'till 5". Of course, I had forgotten that 'minutes' wasn't allowed there (you're free to add it, if you'd like), and since I had it recognizing a date or a time, it interpreted that as "thirty august oh five", the closest available phrase in the grammar, which was a date, not a time. Had it been constrained to just a date, it would have produced a recognition error, as it should have. Try to avoid ambiguous situations like this by limiting how much of your grammar is active at any particular moment.
• Last but not least, under "Tools & File Management", click the "Update Account" button, and uncheck "Occasionally email me product news"...

Good luck with this assignment, and if you're having trouble with something, email me (pmawhorter@gmail.com) or Christine. Also, don't worry too much about building elegant grammars. Feel free to brute-force your grammars to get them to work, and if you find something that would be incredibly painful to implement in a grammar, it's fine to note that you couldn't reasonably accomplish that part of your design and use a simpler placeholder. The assignment says to note things that are impossible, but when it comes to grammars, if you're spending hours trying to get something seemingly simple to work, it falls under the category of "not reasonably possible".