1. 1 Open Source Grammars David Thomson CTO, SpeechPhone (VoiceXML Tools Committee chair) david@speechphone.com

2. 2 VoiceXML Forum Tools Committee Part of the VoiceXML Forum Charter: Make VoiceXML easier to use through better development tools. Members: AT&T, Avaya, Chrysalis, France Telecom, Genesys, IBM, Intervoice, Lumenvox, Nuance, Oracle, SpeechPhone, Voxeo, ….

3. 3 Four Working Groups 1.Metalanguage: Standard language for application servers. 2.Data Logging: Format for capturing run-time data. 3.Advanced Dialogs: Representing non-FSM conversations. 4.Open Source Grammars: Standard grammars for common tasks.

4. 4 Project Overview Objective: Create a set of open-source, standard grammars. Motivation: 1.Make it easier to develop speech applications. 2.Unify the human-machine interface so applications from different vendors have familiar behaviors. 3.VoiceXML 2.0 built-in grammar specification is incomplete.

5. 5 Plans Our task: 1.Gather contributions. 2.Standardization. 3.Conformance & test conditions. 4.Post grammars. 5.Test compliance? Disclaimers: 1.The project is still in early stages. 2.Not everyone agrees with all points in this presentation. 3.Industry is divided on feasibility & value.

6. 6 Project Guidelines 1.Try to create a single grammar for each purpose. 2.Grammars are modular. 3.Use SRGS & SISR. 4.Start with contributions from industry. 5.Use a structured development process. 6.Grammars will be maintained under Sourceforge. 7.Grammars are free and available to everyone. 8.We do not specify the prompt. 9.We define reference grammars that embody the specification and are also useful for developers.

7. 7 Platform Independence Issues Recognizer-independent, platform-independent. We may make note of which platform was used for testing. Reference grammar is portable, but we may add vendor- specific advisory notes. Specify SISR slot name. Standards are implemented differently (CDATA, <, …)

8. 8 Compliance Criteria Options The reference grammar defines the specification. We can test with text input, semantic output. We may establish quality metrics (speed, readability, …). It may be necessary to tailor grammars to application. A grammar variant is compliant if (starting w/least strict): 1.It behaves according to a verbal description (as in VoiceXML 2.0). 2.It satisfies a specification such as an I/O table. 3.It passes a prescribed input/output test. 4.Its output from all possible input exactly matches the reference. (pick one)

9. 9 Development Process 1.Submission - We post all submissions as candidates 2.Selection 3.Develop - Refine grammar - Documentation (includes input/output table, etc.) - Testing requirements & software 4.Validate 5.Post as approved

10. 10 Grammars in Initial Release Boolean (yes/no) Time Date Digits (1-16 digits) Number (1-16 digits) Phone (10 digits) Currency (dollars) Credit Card (card number, expiration date) –With and without Luhn check? Social Security Number VoiceXML built-in grammars

11. 11 Jakarta RDC Atomic Tags Collect a alphanumeric string Collect one choice from a list of options Collect a country name Collect a social security number Collect a international standard book number Collect a percentage Collect a numerical value Collect a string of digits Collect a type of mortgage *Collect mortgage information *Collect credit card information *Composite Collect a date Collect a time Collect a duration Collect a credit card bill amount Collect a credit card expiry date Collect a credit card number Collect a credit card type Collect a zip code Collect a major US city name Collect a US state name Collect a string of alphabets Collect a currency value

12. 12 Existing Grammars RDC Tag Library Voxeo Nuance VoiceXML 2.0 Others…

13. 13 Points by Detractors Creating a quality grammar is expensive. No competent company will participate. There are already several open source grammars. Companies try to differentiate, wont use them. Recognizers & Dev. tools already have grammars. Good applications require customization. –Application & context differences –Platform (CPU, connectivity, ASR) differences –Compatibility with a variety of development tools. –User base variations –Languages –Shifting standards

14. 14 Submission Questions Company name & name of representative Grammar name What is the purpose of the grammar? (~2 sentences) What slots and tokens are returned by the grammar? Examples of input/output (in table form) Is the grammar in SRGS? Is the grammar ABNF or XML? Does the grammar include SISR tags? Attachments (specs, testing procedures & scripts,...) What is the spoken language? Are there any hardware or recognizer dependencies? Was the grammar tested? Deployed? On what platform? Does the grammar depend on other subgrammars? We are contributing the attached grammar for use in the VoiceXML Forum Open Source Grammar project on a royalty-free basis.

15. 15 Open Issues How do we handle multiple versions? –Languages –CPU constraints (embedded) –SRGS/SISR versions –Application dependencies –Grammar updates How do we handle recognizer differences? –Weights –Efficiency tricks –Advanced use of ECMAScript in SISR

16. 16 For More Information Join the Committee email distribution list: Cindy Tiritilli Questions: David Thomson Bill Scholz VoiceXML Forum site www.voicexml.org/grammars