Deciding how to group dialogs

Unlike an HTML page, which is a renderable unit, a VoiceXML document may contain several interactable units such as forms, menus, etc. While you could go to extremes and either write your entire VoiceXML application in a single VoiceXML document or have a separate document for each menu or form, most VoiceXML applications will consist of dialogs and supporting code grouped together into a number of files. For example:

• An application root document for defining global variables, global grammars and global <menu> and <link> elements.
• One or more VoiceXML documents containing the application dialogs or subdialogs.
• Grammar and prerecorded audio files, as required by the application dialogs.
• ECMAScript files, if any.
• Server-side logic for accessing information in back-end enterprise databases.

There are no firm rules for deciding how to group dialogs; however, careful consideration of the following issues can help you decide:

• Logical grouping of menus or forms
• Resources they require
• Functions they perform
• Expected frequency of use
• Number of pages you want the VoiceXML browser to request from the Web application server

For example, you might decide to use a separate VoiceXML document for a form or menu that is executed infrequently and contains a large grammar or references large grammar or audio files. This design will allow the large files to be downloaded only when needed.

Similarly, you might decompose a complex dialog sequence into a series of subdialogs. Subdialogs are also useful for creating reusable components.