Résumé

Ce document définit le langage de balisage extensible vocal (VoiceXML). Le langage VoiceXML se destine à la création des dialogues électro-acoustiques soulignant une voix synthétisée, un signal sonore numérisé, la reconnaissance d'une entrée vocale ou d'une tonalité DTMF, l'enregistrement d'une commande vocale, un échange téléphonique ou des conversations à initiative mixte. Son objectif principal est d'apporter les avantages du développement et de la diffusion de contenu fondés sur le Web aux applications de réponse vocale interactives.

Statut de ce document

Ce chapitre décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications courantes du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ce document, qui a été passé en revue par les membres du W3C et les tiers intéressés, a été approuvé par le Directeur comme recommandation du W3C. Le rôle du W3C en produisant la recommandation consiste à attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Cela participe à la fonctionnalité et l'interopérabilité du Web.

Cette spécification fait partie du Cadre d'interface vocale du W3C et elle a été développée au sein de l'activité Navigateur vocal du W3C par les participants du groupe de travail Navigateur vocal (réservé aux membres du W3C).

La conception du langage VoiceXML 2.0 a fait l'objet d'un examen approfondi (voir la disposition des remarques) et elle satisfait aux exigences techniques du groupe de travail. On trouvera une liste des mises en œuvres dans le rapport des mises en œuvres du langage VoiceXML 2.0, avec la suite de tests associée.

Les remarques sont bienvenues sur la liste de diffusion www-voice@w3.org (archive). Voir également le guide d'utilisation des listes de diffusion et archives du W3C.

Le W3C met à disposition une liste des éventuelles divulgations de brevets relatifs à ces travaux.

Les conventions du document

Dans ce document, les mots-clés doi(ven)t, ne doi(ven)t pas, obligatoire, devra(devront), ne devra(devront) pas, devrai(en)t, ne devrai(en)t pas, recommandé, peu(ven)t et optionnel doivent se comprendre selon les définitions du document [RFC2119] et ils indiquent les niveaux d'obligation des implémentations VoiceXML conformes.

Table des matières

Table des matières abrégée

• 1. Vue d'ensemble
• 2. Les structures de dialogue
• 3. L'entrée d'utilisateur
• 4. La sortie du système
• 5. Le flux de commande et les scripts
• 6. L'environnement et les ressources
• Annexes

Table des matières détaillée

• 1. Vue d'ensemble
  • 1.1 Introduction
  • 1.2 Historique
    • 1.2.1 Le modèle architectural
    • 1.2.2 Les objectifs du langage VoiceXML
    • 1.2.3 La portée du langage VoiceXML
    • 1.2.4 Les principes de conception
    • 1.2.5 Les contraintes de la plateforme d'implémentation
  • 1.3 Les concepts
    • 1.3.1 Les dialogues et les sous-dialogues
    • 1.3.2 Les sessions
    • 1.3.3 Les applications
    • 1.3.4 Les grammaires
    • 1.3.5 Les événements
    • 1.3.6 Les liens
  • 1.4 Les éléments du langage VoiceXML
  • 1.5 La structure et l'exécution du document
    • 1.5.1 L'exécution dans un seul document
    • 1.5.2 L'exécution d'une application à documents multiples
    • 1.5.3 Les sous-dialogues
    • 1.5.4 Le traitement final
• 2. Les structures de dialogue
  • 2.1 Les formulaires
    • 2.1.1 L'interprétation des formulaires
    • 2.1.2 Les éléments de formulaire
    • 2.1.3 Les variables et contraintes des éléments de formulaire
    • 2.1.4 Les formulaires dirigés
    • 2.1.5 Les formulaires à initiative mixte
    • 2.1.6 L'algorithme d'interprétation des formulaires
  • 2.2 Les menus
    • 2.2.1 L'élément menu
    • 2.2.2 L'élément choice
    • 2.2.3 Les tonalités DTMF dans les menus
    • 2.2.4 L'élément enumerate
    • 2.2.5 La génération des grammaires
    • 2.2.6 Le modèle d'interprétation
  • 2.3 Les éléments de formulaire
    • 2.3.1 L'élément field
    • 2.3.2 L'élément block
    • 2.3.3 L'élément initial
    • 2.3.4 L'élément subdialog
    • 2.3.5 L'élément object
    • 2.3.6 L'élément record
    • 2.3.7 L'élément transfer
  • 2.4 L'élément filled
  • 2.5 Les liens
• 3. L'entrée d'utilisateur
  • 3.1 Les grammaires
    • 3.1.1 Les grammaires vocales
    • 3.1.2 Les grammaires DTMF
    • 3.1.3 La portée des grammaires
    • 3.1.4 L'activation des grammaires
    • 3.1.5 L'interprétation sémantique de l'entrée
    • 3.1.6 L'application des résultats de l'interprétation sémantique aux formulaires VoiceXML
• 4. La sortie du système
  • 4.1 L'élément prompt
    • 4.1.1 Le balisage vocal
    • 4.1.2 Les invites de base
    • 4.1.3 L'invite sonore
    • 4.1.4 L'élément value
    • 4.1.5 L'interruption
    • 4.1.6 La sélection d'une invite
    • 4.1.7 La temporisation
    • 4.1.8 La mise en file d'attente des invites et la collecte des entrées
• 5. Le flux de commande et les scripts
  • 5.1 Les variables et les expressions
    • 5.1.1 La déclaration des variables
    • 5.1.2 Les portées des variables
    • 5.1.3 L'appel des variables
    • 5.1.4 Les variables de session normalisées
    • 5.1.5 Les variables d'application normalisées
  • 5.2 La gestion des événements
    • 5.2.1 L'élément throw
    • 5.2.2 L'élément catch
    • 5.2.3 La notation abrégée
    • 5.2.4 La sélection de l'élément catch
    • 5.2.5 Les éléments catch implicites
    • 5.2.6 Les types d'événement
  • 5.3 Le contenu exécutable
    • 5.3.1 L'élément var
    • 5.3.2 L'élément assign
    • 5.3.3 L'élément clear
    • 5.3.4 Les éléments if, elseif et else
    • 5.3.5 Les éléments prompt
    • 5.3.6 L'élément reprompt
    • 5.3.7 L'élément goto
    • 5.3.8 L'élément submit
    • 5.3.9 L'élément exit
    • 5.3.10 L'élément return
    • 5.3.11 L'élément disconnect
    • 5.3.12 L'élément script
    • 5.3.13 L'élément log
• 6. L'environnement et les ressources
  • 6.1 La mise en place des ressources
    • 6.1.1 Le chargement
    • 6.1.2 La mise en cache
    • 6.1.3 Le préchargement
    • 6.1.4 Les protocoles
  • 6.2 Les informations de métadonnée
    • 6.2.1 L'élément meta
    • 6.2.2 L'élément metadata
  • 6.3 L'élément property
    • 6.3.1 Les propriétés propres à la plateforme
    • 6.3.2 Les propriétés génériques des logiciels de reconnaissance vocale
    • 6.3.3 Les propriétés génériques des logiciels de reconnaisance DTMF
    • 6.3.4 Les propriétés d'invite et de collecte
    • 6.3.5 Les propriétés de mise en place
    • 6.3.6 Les propriétés diverses
  • 6.4 L'élément param
  • 6.5 Les désignations des valeurs
• Annexes
  • Annexe A. Le glossaire des termes
  • Annexe B. La définition de type de document VoiceXML
  • Annexe C. L'algorithme d'interprétation des formulaires
  • Annexe D. Les propriétés de temporisation
  • Annexe E. Les formats des fichiers sons
  • Annexe F. La conformité
  • Annexe G. L'internationalisation
  • Annexe H. L'accessibilité
  • Annexe I. La vie privée
  • Annexe J. Les changements survenus depuis VoiceXML 1.0
  • Annexe K. La réutilisabilité
  • Annexe L. Remerciements
  • Annexe M. Références
  • Annexe N. Le type de média et le suffixe de fichier
  • Annexe O. La définition du schéma XML du langage VoiceXML
  • Annexe P. Les types des grammaires intégrées

1. Vue d'ensemble

Ce document definit le langage de balisage extensible vocal. Ses origines, ses concepts fondamentaux et son usage sont présentés dans le chapitre 1. Les structures de dialogue des formulaires, des menus et des liens, ainsi que le mécanisme (l'algorithme d'interprétation des formulaires FIA) de leur interprétation, sont introduits ensuite dans le chapitre 2. Les entrées d'utilisateur employant des grammaires vocales ou DTMF sont abordées dans le chapitre 3, tandis que le chapitre 4 couvre les sorties système faisant appel à une voix synthétisée ou un signal sonore enregistré. Les mécanismes de manipulation du flux de commande des dialogues, comprenant les variables, les événements et les éléments exécutables, sont expliqués dans le chapitre 5. Les caractéristiques environnementales, tels que les paramètres et les propriétés tout comme la manipulation des ressources, sont définies dans le chapitre 6. Les annexes fournissent des renseignements supplémentaires concernant le schéma VoiceXML, la spécification détaillée de l'algorithme FIA, la temporisation, les formats des fichiers sons, les instructions relatives à la conformité, l'internationalisation, l'accessibilité et la vie privée.

Le langage VoiceXML trouve son origine en 1995 comme langage de création de dialogues fondé sur XML et destiné à simplifier le processus de développement des applications de reconnaissance vocale dans un projet de la société AT&T intitulé langage de balisage téléphonique (PML). Conséquence de la réorganisation de la société AT&T, des équipes des sociétés AT&T, Lucent et Motorola ont poursuivis des travaux sur leurs propres langages analogues à PML.

En 1998, le W3C a accueilli une conférence sur les navigateurs vocaux. À cette époque, les sociétés AT&T et Lucent avaient produit des variantes différentes de leur langage PML original, tandis que la société Motorola avait développé le langage VoxML et que la société IBM développait son propre langage SpeechML. Beaucoup d'autres participants de la conférence développaient également des langages similaires pour la création de dialogues, par exemple, le langage TalkML de la société HP et le langage VoiceHTML de la société PipeBeach.

Le forum VoiceXML fut alors constitué par les sociétés AT&T, IBM, Lucent et Motorola afin de mettre leurs efforts en commun. La mission du forum VoiceXML consistait à définir un langage de création de dialogues normalisé dont les développeurs pourraient se servir pour construire des applications conversationnelles. Les membres du forum choisirent le langage XML comme fondement de leur effort car il était clair que c'était l'orientation technologique à prendre.

En 2000, le forum VoiceXML publiait la spécification VoiceXML 1.0. Peu de temps après, le langage VoiceXML 1.0 était soumis au W3C comme fondement pour la création d'un nouveau standard international. Le langage VoiceXML 2.0 résulte de ces travaux ainsi que des suggestions faites par les sociétés membres du W3C, les autres groupes de travail du W3C et le public.

Les développeurs familiarisés avec le langage VoiceXML 1.0 sont invités, en particulier, à consulter le chapitre Les changements survenus depuis VoiceXML 1.0 qui résume les différences entre les deux versions VoiceXML 2.0 et VoiceXML 1.0.

1.1 Introduction

Le langage VoiceXML est destiné à la création des dialogues électro-acoustiques soulignant une voix synthétisée, un signal sonore numérisé, la reconnaissance d'une entrée vocale ou d'une tonalité DTMF, l'enregistrement d'une commande vocale, un échange téléphonique ou des conversations à initiative mixte. Son objectif principal est d'apporter les avantages du développement et de la diffusion de contenu fondés sur le Web aux applications de réponse vocale interactives.

Voici deux exemples VoiceXML brefs. Le premier est l'habituel Salut tout le monde ! :

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
  <form>
    <block>Salut tout le monde !</block>
  </form>
</vxml>

L'élément supérieur est l'élément vxml, dont le rôle principal est celui d'un conteneur pour les dialogues. Il existe deux types de dialogues : les formulaires et les menus. Les formulaires présentent des informations et recueillent les entrées ; les menus présentent des choix pour la suite de l'interaction. Cet exemple montre un seul formulaire contenant un élément block qui synthétise et présente Salut tout le monde ! à l'utilisateur. Comme le formulaire ne précise pas de dialogue suivant, la conversation s'achève.

Notre second exemple propose un choix de boissons à l'utilisateur pour le soumettre à un script côté serveur :

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
  <form>
  <field name="boisson">
     <prompt>Voulez-vous du café, du thé, du lait ou rien du tout ?</prompt>
     <grammar src="boisson.grxml" type="application/srgs+xml"/>
  </field>
  <block>
     <submit next="http://www.boisson.example.com/boisson2.asp"/>
  </block>
 </form>
</vxml>

Un élément field est un champ d'entrée. L'utilisateur doit fournir une valeur au champ avant le traitement de l'élément suivant du formulaire. Voici une interaction simple :

O (ordinateur) : Voulez-vous du café, du thé, du lait ou rien du tout ?

H (humain) : Du jus d'orange.

O : Je n'ai pas compris ce que vous avez dit (un message implicite propre à la plateforme.)

O : Voulez-vous du café, du thé, du lait ou rien du tout ?

H : Du thé.

O : (suite dans le document boisson2.asp)

1.2 Historique

Ce chapitre contient un modèle architectural de haut niveau, dont on utilise ensuite la terminologie pour décrire les objectifs du langage VoiceXML, sa portée, ses principes de conception et les contraintes qu'il exerce sur les systèmes qui le mettent en œuvre.

1.2.1 Le modèle architectural

Le modèle architectural adopté par ce document contient les composants suivants :

Figure 1 : Le modèle architectural

Un serveur de documents (par exemple, un serveur Web) traite les requêtes issues d'une application cliente, à savoir l'interpréteur VoiceXML, au travers du contexte d'interprétation VoiceXML. En réponse, le serveur produit des documents VoiceXML lesquels sont traités par l'interpréteur VoiceXML. Le contexte d'interprétation VoiceXML peut surveiller les entrées des utilisateurs en parallèle avec l'interpréteur VoiceXML. Par exemple, un contexte d'interprétation VoiceXML peut rester en permanence à l'écoute d'une phrase d'abandon particulière qui mène l'utilisateur à un assistant personnel de haut niveau et un autre rester à l'écoute de phrases d'abandon qui modifient les préférences de l'utilisateur comme le volume ou bien les caractéristiques de la synthèse de la parole.

La plateforme d'implementation est commandée par le contexte d'interprétation VoiceXML et par l'interpréteur VoiceXML. Par exemple, dans une application de réponse vocale interactive, le contexte d'interprétation VoiceXML peut être responsable de la détection d'un appel entrant, de l'acquisition du document VoiceXML initial et de la réponse à cet appel, tandis que l'interpréteur VoiceXML conduit le dialogue après l'appel. La plateforme d'implémentation suscite des événements en réponse aux actions de l'utilisateur (par exemple, se déconnecter dès réception d'une entrée vocale ou d'une saisie de caractères) et aux événements du système (par exemple, l'expiration d'un temporisateur). L'interpréteur VoiceXML interfère, selon les indications du document VoiceXML, sur certains de ces événements, tandis que le contexte d'interprétation VoiceXML interfère sur d'autres.

1.2.2 Les objectifs du langage VoiceXML

L'objectif principal du langage VoiceXML est d'apporter la pleine puissance de développement et de diffusion de contenu du Web aux applications de réponse vocale, en libérant ainsi leurs auteurs de la programmation et de la gestion des ressources de bas niveau. Ce qui permet l'intégration des services vocaux aux et des services d'accès aux données en utilisant le paradigme client-serveur familier. Un service vocale apparaît comme une succession de dialogues d'interaction entre un utilisateur et une plateforme d'implémentation. Les dialogues sont fournis par des serveurs de documents, lesquels peuvent être extérieurs à la plateforme d'implémentation. Les serveurs de documents se chargent de la logique d'ensemble des services, de l'exploitation des bases de données et des systèmes patrimoniaux, et produisent les dialogues. Le document VoiceXML précise chacun des dialogues d'interaction que l'interpréteur VoiceXML doit conduire. Les entrées d'utilisateur affectent l'interprétation du dialogue et elles sont rassemblées en requêtes soumises au serveur de documents. Le serveur de documents répond par un autre document VoiceXML afin de poursuivre la session avec l'utilisateur par d'autres dialogues.

Le langage VoiceXML est un langage de balisage qui :

• Minimise les interactions client/serveur en définissant plusieurs interactions par document.

• Isole les auteurs d'applications des détails de bas niveau propres à la plateforme.

• Sépare le code d'interaction avec l'utilisateur (dans le langage VoiceXML) de la logique des services (par exemple, les scripts CGI).

• Favorise la portabilité des services entre les plateformes d'implémentation. Le langage VoiceXML est commun aux fournisseurs de contenu, aux fournisseurs d'outils et aux fournisseurs de plateformes.

• Est facile à employer pour des interactions simples et offre néanmoins des fonctionnalités pour gérer des dialogues complexes.

Bien que le langage VoiceXML s'efforce de satisfaire aux besoins d'une majorité de services à réponse vocale, il est probable que des applications dédiées, agissant à un niveau d'action plus fin, soient mieux adaptées aux exigences strictes de certains services.

1.2.3 La portée du langage VoiceXML

Le langage décrit l'interaction homme-machine offerte par les systèmes à réponse vocale, ce qui comprend :

• La sortie d'une voix synthétisée (synthèse de la parole).

• La sortie de fichiers sons.

• La reconnaissance d'une entrée vocale.

• La reconnaissance d'une entrée DTMF.

• L'enregistrement d'une commande vocale.

• La commande du flux des dialogues.

• Des fonctionnalités téléphoniques tels que le transfert d'appel et le raccrochage.

Le langage VoiceXML fournit les moyens de capturer une saisie de caractères et/ou une commande vocale, en assignant les résultats des entrées à des variables de requête définies par le document et en prenant des décisions qui affectent l'interprétation des documents écrits dans ce même langage. Un document peut être relié à d'autres documents par le biais d'identificateurs de ressource uniformes (URI).

1.2.4 Les principes de conception

Le langage VoiceXML est une application XML [XML].

1. Le langage encourage la portabilité des services au travers d'une abstraction des ressources des plateformes.

2. Le langage s'accomode de la diversité des plateformes en ce qui concerne la gestion des formats des fichiers sons, des formats des grammaires vocales et des systèmes d'adresse URI. Bien que les fabricants de plateformes puissent gérer divers formats de grammaire, le langage nécessite un format de grammaire commun, à savoir la forme XML décrite dans la spécification des grammaires de reconnaissance vocale du W3C [SRGS], pour faciliter l'interopérabilité. De la même manière, bien que divers formats sonores de lecture et d'enregistrement puissent être gérés, ceux décrits dans l'annexe E doivent être pris en charge.

3. Le langage offre des facilités pour la création des types d'interaction courants.

4. Le langage possède une sémantique bien définie qui préserve les intentions de l'auteur en ce qui concerne le déroulement des interactions avec l'utilisateur. Il n'est pas besoin d'une heuristique côté client pour déterminer l'interprétation des éléments d'un document.

5. Le langage reconnaît les interprétations sémantiques faites par les grammaires et il transmet ces informations à l'application.

6. Le langage est doté d'un mécanisme de flux de commande.

7. Le langage autorise une séparation entre la logique du service et le comportement d'une interaction.

8. Le langage n'est pas conçu pour des calculs intensifs, pour l'exploitation des bases de données ou l'exploitation des systèmes patrimoniaux. Toutes choses que des ressources situées hors de l'interpréteur du document sont censés prendre en charge, par exemple, un serveur de documents.

9. La logique de service générale, la gestion des états, la génération et la succession des dialogues sont censées résider hors de l'interprétateur du document.

10. Le langage permet de relier des documents et aussi de soumettre des données à des scripts côté serveur au moyen d'adresses URI.

11. Le langage VoiceXML permet d'identifier exactement quelles données soumettre au serveur et quelle méthode HTTP (GET ou POST) employer pour la soumission.

12. Le langage n'exige pas des auteurs de documents qu'ils affectent ou désaffectent explicitement les ressources des dialogues ou qu'ils se préoccupent des accès simultanés. L'allocation des ressources et les fils de commande concurrents doivent être pris en charge par la plateforme d'implémentation.

1.2.5 Les contraintes de la plateforme d'implémentation

Ce chapitre souligne les contraintes exercées sur les plateformes matérielles/logicielles qui soutiendront un interpréteur VoiceXML.

L'acquisition du document. Le contexte d'interprétation est censé acquérir les documents sur lesquels l'interpréteur VoiceXML agira. La gestion du système d'adresse URI http:// est obligatoire. Dans certains cas, la requête des documents est générée par l'interprétation d'un document VoiceXML, tandis que d'autres requêtes sont générées par le contexte d'interprétation en réponse à des événements hors de portée du langage, par exemple, un appel téléphonique entrant. Lorsqu'il émet des requêtes de documents via le protocole HTTP, le contexte d'interprétation s'identifie au moyen d'une variable d'en-tête User-Agent dont la valeur a la forme nom/version, par exemple, "acme-browser/1.2"

La sortie audio. Une plateforme d'implémentation doit mettre en œuvre une sortie audio utilisant des fichiers sons et une voix synthétisée. La plateforme doit pouvoir ordonner librement la synthèse vocale et la sortie audio. Si une ressource de sortie audio n'est pas disponible, alors un événement error.noresource doit être suscité. Les fichiers sons sont appelés par des adresses URI. Le langage définit un ensemble obligatoire de formats de fichiers sons (voir l'annexe E) ; d'autres formats de fichiers sons peuvent également être gérés.

L'entrée audio. Une plateforme d'implémentation est tenue de détecter et signaler simultanément une saisie de caractères et/ou une commande vocale et de contrôler la durée de l'intervalle de détection d'une entrée avec un temporisateur dont la longueur est spécifiée par un document VoiceXML. Si une ressource de sortie audio n'est pas disponible, alors un événement error.noresource doit être suscité.

• La plateforme doit signaler les caractères (par exemple, DTMF) saisis par un utilisateur. Les plateformes doivent prendre en charge la forme XML des grammaires décrites dans la spécification des grammaires de reconnaissance vocale du W3C [SRGS]. Elles devraient également prendre en charge la forme ABNF des grammaires DTMF décrites dans la même spécification [SRGS].

• La plateforme doit pouvoir recevoir dynamiquement les données de la grammaire de reconnaissance vocale. Elle doit pouvoir utiliser les données des grammaires vocales de forme XML de la spécification des grammaires de reconnaissance vocale du W3C [SRGS]. Elle devrait pouvoir recevoir les données des grammaires de reconnaissance vocale de forme ABNF de cette même spécification [SRGS], et elle peut prendre en charge d'autres formes de grammaire tel que le format JSpeech Grammar Format [JSGF] ou bien des formats propriétaires. Certains éléments VoiceXML contiennent des données de grammaire vocale, d'autres se réfèrent à des données de grammaire vocale au travers d'une adresse URI. Le logiciel de reconnaissance vocale doit pouvoir s'adapter à une mise à jour dynamique de la commande vocale qu'il écoute au travers d'une des méthodes décrites dans la spécification des grammaires de reconnaissance vocale.

• La plateforme doit pouvoir enregistrer les signaux sonores provenant de l'utilisateur. La plateforme d'implémentation doit faire en sorte que l'enregistrement soit disponible à une variable de requête. Le langage définit un ensemble obligatoire de formats de fichiers sons enregistrés (voir l'annexe E) ; d'autres formats peuvent également pris en charge.

Le transfert. La plateforme devrait pouvoir effectuer une connexion à un tiers au travers d'un réseau de communication, tel que le réseau téléphonique.

1.3 Les concepts

Un document VoiceXML (ou bien un ensemble de documents apparentés appelé application) forme une machine conversationnelle à états finis. L'utilisateur se trouve toujours dans un seul état conversationnel (ou dialogue) à la fois. Chaque dialogue détermine le prochain dialogue de transition. Les transitions sont indiquées au moyen d'adresses URI, lesquelles définissent les prochains document et dialogue à utiliser. Si l'adresse URI ne désigne pas de document, alors il s'agit du document courant. Si elle ne désigne pas de dialogue, alors il s'agit du premier dialogue dans le document. L'exécution se termine lorsque le dialogue n'indique pas de successeur ou bien lorsqu'il contient un élément qui interrompt explicitement la conversation.

1.3.1 Les dialogues et les sous-dialogues

Il existe deux types de dialogues : les formulaires et les menus. Les formulaires définissent une interaction qui effectue la collecte des valeurs d'un ensemble de variables d'élément de formulaire. Chaque champ peut indiquer une grammaire définissant les entrées permises dans celui-ci. Si une grammaire au niveau du formulaire est présente, alors elle peut servir pour le remplissage de plusieurs champs d'un énoncé. Un menu présentera à l'utilisateur un ensemble d'options puis il effectuera une transition vers un autre dialogue en fonction de son choix.

Un sous-dialogue ressemble à un appel de fonction en cela qu'il fournit un mécanisme pour invoquer une nouvelle interaction pour revenir ensuite au formulaire original. Les instances de variables, les grammaires et les information d'états sont sauvegardées et sont disponibles au retour sur le document appelant. Les sous-dialogues peuvent servir, par exemple, à créer une séquence de confirmation nécessitant l'interrogation d'une base de données, ou à créer un ensemble de composants susceptibles d'être partagés entre des documents dans une seule application, ou à créer une librairie de dialogues réutilisables partagée entre plusieurs applications.

1.3.2 Les sessions

Une session débute lorsque l'utilisateur commence à interagir avec un contexte d'interprétation VoiceXML et s'achève à la demande de l'utilisateur, d'un document ou du contexte d'interprétation.

1.3.3 Les applications

Une application est un ensemble de documents partageant un même document racine d'application. Dès que l'utilisateur interagit avec un document dans une application, le document racine d'application est chargé également. Le document racine d'application reste chargé en mémoire tant que l'utilisateur effectue des transitions entre les autres documents de la même application et il est vidé de la mémoire lorsque l'utilisateur opère une transition vers un document qui ne se trouve pas dans l'application. Tant que le document racine d'application est chargé, ses variables sont accessibles aux autres documents au titre de variables d'application et ses grammaires restent actives pour la durée de l'application, selon les règles d'activation des grammaires expliquées dans le chapitre 3.1.4.

La figure 2 montre les documents de transition (D) dans une application partageant un document racine d'application commun (racine).

Figure 2 : Les documents de transition dans une application.

1.3.4 Les grammaires

Chaque dialogue a une ou plusieurs grammaires vocales et/ou DTMF associées. Dans les applications dirigées par la machine, toutes les grammaires d'un dialogue ne sont actives que lorsque l'utilisateur se trouve dans le dialogue en question. Dans les applications à initiative mixte, où l'utilisateur et la machine déterminent en alternance quoi faire ensuite, certains dialogues sont marqués pour rendre leurs grammaires actives (c'est-à-dire, à l'écoute), même si l'utilisateur se trouve dans un autre dialogue du même document, ou dans un autre document chargé issu de la même application. Dans cette situation, si l'utilisateur dit quelque chose touchant les grammaires actives d'un autre dialogue, l'exécution opère une transition vers cet autre dialogue, l'énoncé de l'utilisateur étant alors traité comme s'il avait été dit dans ce dialogue. L'initiative mixte apporte de la puissance et de la flexibilité aux applications vocales.

1.3.5 Les événements

Le langage VoiceXML fournit un mécanisme de remplissage de formulaire pour la manipulation normale d'une entrée d'utilisateur. Il définit, en outre, un mécanisme pour la gestion des événements non couverts par le mécanisme du formulaire.

La plateforme suscite des événements dans diverses circonstances, comme lorsque l'utilisateur ne répond pas, ou ne répond pas de manière intelligible, demande de l'aide, etc. L'interpréteur suscite également des événements s'il trouve une erreur sémantique dans un document VoiceXML. Les événements sont capturés par des éléments catch ou leur forme syntaxique abrégée. Tout élément dans lequel un événement peut survenir peut définir des éléments catch. En outre, les éléments catch peuvent également s'hériter des éléments englobants comme par copie. On peut ainsi spécifier un comportement de gestion des événements communs à n'importe quel niveau, lequel s'applique à tous les niveaux inférieurs.

1.3.6 Les liens

Le lien gère les interactions d'initiative mixte. Il définit une grammaire active dès lors que l'utilisateur se trouve dans la portée du lien. Si l'entrée d'utilisateur correspond à la grammaire indiquée par le lien, le contrôle est transféré à l'adresse URI de ce lien. Un lien peut servir à susciter un événement ou à aller sur l'adresse URI de destination.

1.4 Les éléments du langage VoiceXM

1.5 La structure et l'exécution du document

Un document VoiceXML se compose principalement d'éléments de niveau supérieur appelés dialogues. Il existe deux types de dialogues : les formulaires et les menus. Un document peut également avoir des éléments meta et metadata, des éléments var et script, des éléments property, des éléments catch et des éléments link.

1.5.1 L'exécution dans un seul document

L'exécutions du document débute implicitement au premier dialogue. Au fur et à mesure de l'exécution, chaque dialogue détermine le suivant. Lorsqu'un dialogue n'indique aucun dialogue suivant, l'exécution du document se termine.

Voici développé un Salut tout le monde ! afin d'illustrer ce déroulement. L'exemple inclut maintenant une variable de niveau document appelée salut et contenant le message d'accueil. Sa valeur sert d'invite dans le premier formulaire. Dès lors que ce premier formulaire a joué le message d'accueil, il va au formulaire appelé dire_au_revoir, lequel joue Au revoir ! à l'utilisateur. Puisque le second formulaire ne fait aucune transition vers un autre dialogue, cela provoque une sortie du document.

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
 <meta name="author" content="John Doe"/>
 <meta name="maintainer" content="sav-salut@salut.example.com"/>
 <var name="salut" expr="'Salut tout le monde !'"/>
 <form>
  <block>
     <value expr="salut"/>
     <goto next="#dire_au_revoir"/>
  </block>
 </form>
 <form id="dire_au_revoir">
  <block>
     Au revoir !
  </block>
 </form>
</vxml>

Les formulaires peuvent se combiner autrement :

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
 <meta name="author" content="John Doe"/>
 <meta name="maintainer" content="sav-salut@salut.example.com"/>
 <var name="salut" expr="'Bonjour tout le monde !'"/>
 <form>
  <block>
     <value expr="salut"/> Au revoir !
  </block>
 </form>
</vxml>

L'élément vxml comprend les attributs suivants :

L'information de langue s'hérite en descendant la hiérarchie du document : la valeur de l'attribut xml:lang se transmet aux éléments susceptibles de définir également cet attribut, tels que les éléments grammar et prompt, à moins que ces éléments ne définissent une autre valeur.

1.5.2 L'exécution d'une application à documents multiples

Normalement, chaque document s'exécute comme une application isolée. Dans les cas où l'on souhaite que plusieurs documents travaillent ensemble comme une seule application, on sélectionne un document afin qu'il devienne le document racine d'application, les autres documents devenant des documents terminaux d'application. Chaque document terminal indique alors le document racine dans son élément vxml.

Une fois cette indication donnée, à chaque fois que l'interpréteur sera instruit de charger et d'exécuter un document terminal dans cette application, il chargera d'abord le document racine d'application si ce n'était pas déjà fait. Le document racine d'application reste chargé jusqu'à ce que l'interpréteur soit instruit de charger un document appartenant à une application différente. De ce fait, l'interprétation se situera toujours dans l'un des deux cas de figure suivants :

• Le document racine d'application est chargé et l'utilisateur interagit avec celui-ci : il n'y a pas de document terminal.

• Le document racine d'application et un seul document terminal sont tous les deux chargés et l'utilisateur interagit avec le document terminal.

Lorsqu'on définit une succession de sous-dialogues dans des documents séparés, plusieurs documents terminaux peuvent avoir été chargés, bien que l'exécution ne se situe que dans l'un de ces documents.

Lorsque le chargement d'un document terminal déclenche celui d'un document racine d'application, aucun des dialogues dans le document racine n'est exécuté. L'exécution débute dans le document terminal.

Les applications à multiples documents revêtent plusieurs avantages :

• Les variables du document racine sont disponibles pour les documents terminaux, de sorte que les informations peuvent être partagées et conservées.
• Les éléments property du document racine définissent les valeurs implicites des propriétés utilisées dans les documents terminaux.
• On peut définir du code ECMAScript courant dans les éléments script du document racine, code qui peut servir dans les documents terminaux.
• Les éléments catch du document racine définissent la gestion implicite des événements pour les documents terminaux.
• Les grammaires de portée document dans le document racine sont actives lorsque l'utilisateur se trouve dans un document terminal, de sorte que l'utilisateur peut interagir avec les formulaires, liens et menus dans le document racine.

Voici l'illustration d'une application en deux documents :

Document racine d'application (racine-app.vxml)

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
 <var name="au_revoir" expr="« Ciao »"/>
 <link next="transfert_operateur.vxml">
   <grammar type="application/srgs+xml" root="racine" version="1.0">
     <rule id="racine" scope="public">opérateur</rule>
  </grammar>
 </link>
</vxml>

Document terminal (terminal.vxml)

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0" application="racine-app.vxml">
 <form id="dire_au_revoir">
  <field name="reponse">
     <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
     <prompt>Devons-nous nous dire <value expr="application.au_revoir"/> ?</prompt>
     <filled>
       <if cond="reponse">
        <exit/>
       </if>
       <clear namelist="reponse"/>
     </filled>
  </field>
 </form>
</vxml>

Dans cet exemple, l'application est conçue de telle sorte que le document terminal.vxml doive être chargé en premier. Son attribut application indique que le document racine_app.vxml devrait être utilisé comme document racine d'application. Le document racine_app.vxml est donc chargé, ce qui crée la variable d'application au_revoir et définit également un lien qui mène au document transfert_operateur.vxml dès lors que l'utilisateur dit opérateur. L'utilisateur commence l'interaction dans le formulaire dire_au_revoir :

O : Devons-nous nous dire « Ciao » ?

H : Si !

O : Je n'ai pas compris ce que vous avez dit (un message implicite propre à la plateforme).

O : Devons-nous nous dire « Ciao » ?

H : Ciao !

O : Je n'ai pas compris ce que vous avez dit.

H : Opérateur.

O : (Charge le document transfert_operateur.vxml, afin de mettre l'appelant en contact avec un opérateur humain).

Remarquez que, quand l'utilisateur est dans une application à documents multiples, deux documents au plus sont chargés à tout instant : le document racine d'application et, sauf si effectivement l'utilisateur interagit avec le document racine, un document terminal de l'application. L'élément vxml du document racine ne définit pas d'attribut application et, au contraire, c'est l'élément vxml d'un document terminal qui définit un attribut application. Un interpréteur aura toujours un document racine d'application chargé, mais un document terminal d'application ne le sera pas toujours.

Le nom de l'application courante de l'interpréteur est l'adresse URI absolue du document racine d'application. L'interpréteur demeure dans la même application tant que le nom reste le même. Lorsque le nom change, il entre dans une nouvelle application et son contexte racine est initialisé. Le contexte racine de l'application se compose des variables, des grammaires, des éléments catch, des scripts et des propriétés dans la portée de l'application.

Pendant une session d'utilisateur, l'interpréteur passe d'un document à l'autre selon les requêtes des éléments choice, goto, link, subdialog et submit. Certaines transitions restent dans une application, d'autres ont lieu entre des applications. La préservation ou l'initialisation du contexte racine dépendent du type de la transition :

Transition racine à terminal dans l'application

Une transition racine à terminal dans la même application se produit lorsque le document courant est un document racine et que la valeur de l'attribut application du document cible se résoud dans la même adresse URI absolue que celle du nom de l'application courante. Le document racine d'application et son contexte sont préservés.

Transition terminal à terminal dans l'application

Une transition terminal à terminal dans la même application se produit lorsque le document courant est un document terminal et que la valeur de l'attribut application du document cible se résoud dans la même adresse URI absolue que celle du nom de l'application courante. Le document racine d'application et son contexte sont préservés.

Transition terminal à racine dans l'application

Une transition de terminal à racine dans la même application se produit lorsque le document courant est un document terminal et que l'adresse URI absolue du document cible est la même que celle du nom de l'application courante. Le document racine d'application courant et son contexte sont préservés quand la transition est causée par un élément choice, goto ou link. Le contexte racine est initialisé quand c'est un élément submit qui produit la transition terminal à racine, car l'élément submit aboutit toujours au chargement de son adresse URI.

Transition racine à racine

Une transition racine à racine se produit lorsque le document courant est un document racine et le document cible aussi, c'est-à-dire qu'il n'a pas d'attribut application. Le contexte racine est initialisé par le document racine d'application conformément à la politique de mise en cache, voir le chapitre 6.1.2. La politique de mise en cache est consultée, même lorsque le nom de l'application cible et celui de l'application courante sont identiques.

Transition de sous-dialogue

L'invocation d'un sous-dialogue se produit lorsqu'un document racine ou un document terminal exécutent un élément subdialog. Comme expliqué dans le chapitre 2.3.4, l'invocation d'un sous-dialogue crée un nouveau contexte d'exécution. Le document racine d'application et son contexte, dans le contexte d'exécution du document appelant, sont gardés intacts pendant l'exécution du sous-dialogue puis réutilisés au retour du sous-dialogue en question. Le nouveau contexte d'exécution du sous-dialogue possède son propre contexte racine et, le cas échéant, son propre contexte terminal. Lorsqu'un appel d'adresse URI non vide invoque le sous-dialogue, c'est la politique de mise en cache, décrite dans le chapitre 6.1.2, qui déterminera l'acquisition des documents racine et terminal utilisés pour initialiser les nouveaux contextes racine et terminal. Si un sous-dialogue est invoqué au travers d'un appel d'adresse URI vide avec un identificateur de fragment, par exemple, #sous-routine1, alors le document racine et le document terminal demeurent inchangés, et c'est la raison pour laquelle les documents racine et terminal courants seront utilisés pour initialiser les nouveaux contextes racine et terminal.

Les transitions inter-applications

Toutes les autres transitions se produisent entre applications, ce qui se traduit par une initialisation du contexte racine de l'application par le document racine de l'application suivante.

Si un document se réfère à un document racine d'application inexistant, un événement error.badfetch est suscité. Si l'attribut application d'un document se réfère à un document qui possède déjà un attribut application, alors un événement error.semantic est suscité.

Les diagrammes suivants illustrent les effets des transitions entre les documents racine et terminal et le contexte racine de l'application. Dans ces diagrammes, les boîtes représentent des documents, les changements de texture des boîtes identifient les initialisations de contexte racine, les flèches en trait plein symbolisent les transitions vers l'adresse URI dans l'étiquette de la flèche, les flèches verticales en pointillés indiquent un attribut application dont l'adresse URI correspond à l'étiquette de la flèche.

Figure 3 : Les transitions qui préservent le contexte racine

Dans ce diagramme, tous les documents appartiennent à la même application. Les transitions sont identifiées par les numéros de 1 à 4 dans la partie supérieure de la figure. Ce sont :

1. Une transition vers une adresse URI A qui résulte dans le document 1, le contexte d'application est initialisé à partir du contenu du document 1. Supposons que ce soit le premier document de la session. Le nom de l'application courante est A.
2. Les document 1 définit une transition vers l'adresse URI B, laquelle produit le document 2. L'attribut application du document 2 et l'adresse URI A ont la même valeur. La racine est le document 1 dont le contenu est préservé. C'est une transition racine à terminal dans la même application.
3. Le document 2 définit une transition vers l'adresse URI C, laquelle produit un autre document terminal : le document 3. La valeur de son attribut application est identique également à l'adresse URI A. La racine est le document 1 dont le contenu est préservé. C'est une transition terminal à terminal dans la même application.
4. Le document 3 définit une transition vers l'adresse URI A au moyen d'un élement choice, goto ou link. Le document 1 est utilisé avec son contexte racine intact. C'est une transition terminal à racine dans la même application.

Le diagramme suivant illustre des transitions qui initialisent le contexte racine.

Figure 4 : Les transitions qui initialisent le contexte racine

5. Le document 1 définit une transition vers sa propre adresse URI A. Le document résultant 4 n'a pas d'attribut application, il s'agit donc un document racine et le contexte racine est initialisé. C'est une transition racine à racine.
6. Le document 4 définit une transition vers l'adresse URI D, laquelle produit le document terminal 5. La valeur de son attribut application est différente : l'adresse URI E. On entre dans une nouvelle application. L'adresse URI E produit le document racine 6. Le contexte racine est initialisé à partir du contenu du document 6. C'est une transition inter-applications.
7. Le document 5 définit une transition vers l'adresse URI A. La consultation du cache renvoie le document 4 lequel n'a pas d'attribut application. Par conséquent, il appartient à l'application A et le contexte racine est donc initialisé. L'initialisation a lieu, même si cette application et ce document racine ont été utilisés plus tôt dans la session. C'est une transition inter-applications.

1.5.3 Les sous-dialogues

Un sous-dialogue est un mécanisme permettant de décomposer des séquences de dialogues complexes afin de mieux les structurer ou de créer des composants réutilisables. Par exemple, la sollicitation des renseignements concernant un compte peut impliquer de réunir plusieurs informations, tels qu'un numéro de compte et un numéro de téléphone du domicile. Un service d'assistance à la clientèle pourrait se construire autour de plusieurs applications indépendantes partageant ce bloc de construction élémentaire, qu'il serait donc raisonnable de construire comme un sous-dialogue. On en trouvera une illustration dans l'exemple ci-dessous. Le premier document app.vxml cherche à régulariser le compte d'un client et, pour ce faire, il doit obtenir les renseignements concernant le compte puis le niveau de régularisation. Les renseignements sur le compte sont obtenus au moyen d'un élément subdialog qui invoque un autre document VoiceXML, lequel sollicite une entrée de l'utilisateur. Pendant l'exécution de ce second document, le dialogue appelant est suspendu en attente du retour des informations. Le second document fournit le résultat des interactions avec l'utilisateur au moyen d'un élément return, les valeurs résultantes devenant accessibles au travers de la variable définie par l'attribut name sur l'élément subdialog.

Application de service à la clientèle (app.vxml)

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
  <form id="regularisation_facturation">
    <var name="num_compte"/>
    <var name="tel_domicile"/>
    <subdialog name="infocompte" src="info_compte.vxml#normal">
      <filled>
        <!-- Remarquez que la variable définie par "infocompte"
          est renvoyée comme objet ECMAScript, lequel contient deux
          propriétés définies par les variables indiquées dans
          l'élément "return" du sous-dialogue. -->

        <assign name="num_compte" expr="infocompte.numcompte"/>
        <assign name="tel_domicile" expr="infocompte.telcompte"/>
      </filled>
    </subdialog>

    <field name="montant_regularisation">
     <grammar type="application/srgs+xml" src="/grammars/currency.grxml"/>
      <prompt>
        Quelle est la valeur de votre régularisation de compte ?
      </prompt>
      <filled>
        <submit  next="/cgi-bin/majcompte"/>
      </filled>
    </field>
  </form>
</vxml>

Document contenant le sous-dialogue des renseignements de compte (info_compte.vxml)

<?xml version="1.0" encoding="UTF-8"?>
<vxml xmlns="http://www.w3.org/2001/vxml"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd"
   version="2.0">
  <form id="normal">
    <field name="numcompte">
      <grammar type="application/srgs+xml" src="/grammars/digits.grxml"/>
      <prompt> Quel est votre numéro de compte ? </prompt>
    </field>
    <field name="telcompte">
      <grammar type="application/srgs+xml" src="/grammars/phone.grxml"/>
      <prompt> Quel est le numéro de téléphone de votre domicile ? </prompt>
      <filled>
        <!-- Les valeurs obtenues dans les deux champs sont fournies
          au dialogue appelant par l'élément "return". -->
        <return namelist="numcompte telcompte"/>
      </filled>
    </field>
  </form>
</vxml>

Les sous-dialogues ajoutent un nouveau contexte d'exécution lorsqu'on les invoque. Le sous-dialogue peut être un nouveau dialogue dans le document existant ou un nouveau dialogue dans un nouveau document.

Les sous-dialogues peuvent se composer de plusieurs documents. La figure 5 montre le flux d'exécution au cours de la transition d'une séquence de documents (D) vers un sous-dialogue (SD) et retour.

Figure 5 : Un sous-dialogue composé de plusieurs documents
revenant du dernier document de sous-dialogue.

Le contexte d'exécution du dialogue D2 est suspendu pendant l'invocation du sous-dialogue SD1 dans le document sd1.vxml. Ce sous-dialogue transfère l'exécution au dialogue dans le document sd2.vxml (au moyen d'un élément goto). En définitive, le contrôle est rendu directement au dialogue D2 lorsque le dialogue dans sd2.vxml s'achève.

La figure 6 montre un exemple de sous-dialogue en plusieurs documents dans lequel le contrôle est transféré d'un sous-dialogue à l'autre.

Figure 6 : Un sous-dialogue composé de plusieurs documents
revenant du premier document de sous-dialogue.

Le sous-dialogue dans sd1.vxml spécifie un transfert du contrôle vers un second sous-dialogue SD2 dans sd2.vxml. Pendant l'exécution du sous-dialogue SD2, deux contextes sont suspendus : celui du dialogue dans D2 attendant un retour de SD1 et celui du dialogue dans SD1 attendant un retour de SD2. Au retour de SD2, le contrôle revient à SD1, qui redonne à son tour le contrôle au dialogue D2.

1.5.4 Le traitement final

Dans certaines circonstances (notamment, pendant que l'interpréteur VoiceXML traite un événement disconnect), l'interpréteur peut poursuivre l'exécution dans l'état de traitement final après l'interruption d'une connexion, afin de permettre à l'application VoiceXML d'effectuer une éventuelle purge nécessaire finale, telle que soumettre les informations au serveur d'applications. Par exemple, l'élément catch suivant capturera l'événement connection.disconnect.hangup et l'exécutera au cours de l'état de traitement final :

<catch event="connection.disconnect.hangup">
    <submit namelist="maSortie" next="http://monsite/sortie.jsp"/>
</catch>

Pendant l'état de traitement final, l'application doit rester dans l'état de transition et ne peut pas entrer dans l'état d'attente (décrit dans le chapitre 4.1.8). Ainsi, par exemple, l'application ne devrait pas aller dans les éléments field, record et transfer pendant l'état de traitement final. L'interpréteur VoiceXML doit s'interrompre si l'application VoiceXML essaye d'entrer dans l'état d'attente pendant l'état de traitement final.

Hormis cette restriction, l'exécution de l'application VoiceXML se poursuit normalement pendant l'état de traitement final. Ainsi, par exemple, l'application peut effectuer une transition entre des documents pendant l'état de traitement final et l'interpréteur doit s'interrompre si aucun élément de formulaire ne convient pour une sélection (comme décrit dans le chapitre 2.1.1).

2. Les structures de dialogue

2.1 Les formulaires

Les formulaires sont les composants-clés des documents VoiceXML. Un formulaire comprend :

• Un ensemble d'éléments de formulaire, lesquels sont lus par la boucle principale de l'algorithme d'interprétation des formulaires. Les éléments de formulaire se rangent en éléments d'entrée, qui peuvent être remplis par une entrée d'utilisateur, et les éléments de commande, qui ne le peuvent.

• Des déclarations de variables d'élément non-formulaire.

• Des gestionnaires d'événements.

• Des actions remplies, à savoir des blocs de logique procédurale s'exécutant quand certaines combinaisons de variables d'éléments d'entrée sont assignées.

Les attributs de formulaire sont :

Cette partie décrit certains concepts sous-jacents des formulaires puis donne quelques exemples détaillés de leur utilisation.

2.1.1 L'interprétation des formulaires

Les formulaires sont interprétés par un algorithme d'interprétation des formulaires implicite (FIA). La boucle principale de l'algorithme FIA sélectionne à maintes reprises un élément de formulaire pour le visiter. L'élément de formulaire sélectionné est le premier dans l'ordre du document dont la condition de veille n'est pas satisfaite. Par exemple, la condition de veille implicite d'un champ vérifie si la variable d'élément de formulaire du champ possède une valeur, de sorte que, si un formulaire simple ne contient que des champs, l'utilisateur fera l'objet d'une invite pour chaque champ à tour de rôle.

En général, l'interprétation d'un élément de formulaire implique :

• La sélection et la lecture d'une ou plusieurs invites ;

• La collecte d'une entrée d'utilisateur, que ce soit une réponse remplissant un ou plusieurs éléments d'entrée ou bien le déclenchement d'un certain événement (par exemple, une aide), et ;

• L'interprétation de toutes les actions filled correspondant aux éléments d'entrée nouvellement remplis.

L'algorithme FIA se termine lorsqu'il rencontre une déclaration de transfert de contrôle (par exemple, un élément goto menant à un autre dialogue ou document, ou un élément submit envoyant des données au serveur de documents. Il se termine également pour un élément exit implicite, quand il ne reste aucun élément de formulaire susceptible d'être sélectionné.

L'algorithme FIA est décrit précisément dans le chapitre 2.1.6.

2.1.2 Les éléments de formulaire

Les éléments de formulaire sont ceux pouvant être visités dans la boucle principale de l'algorithme FIA. Les éléments d'entrée conduisent l'algorithme FIA à réunir un résultat pour un élément particulier. Lorsque l'algorithme FIA sélectionne un élément de commande, cet élément peut contenir un bloc de code procédural à exécuter, ou il peut dire à l'algorithme FIA de mettre en place l'invite-et-collecte initiale d'un formulaire à initiative mixte.

2.1.2.1 Les éléments d'entrée

Un élément d'entrée définit une variable d'élément d'entrée à recueillir de l'utilisateur. Les éléments d'entrée ont des invites pour indiquer à l'utilisateur quoi dire ou quoi saisir, des grammaires qui définissent les entrées permises et des gestionnaires d'événement pour traiter tous les événements susceptibles d'en résulter. Un élément d'entrée peut également comporter un élément filled, lequel définit l'action à prendre juste après que la variable d'élément d'entrée a été remplie. Les éléments d'entrée comprennent :

2.1.2.2 Les éléments de commande

Il existe deux types d'éléments de commande :

2.1.3 Les variables et contraintes des éléments de formulaire

À chaque élément de formulaire est associée une variable d'élément de formulaire, dont la valeur implicite n'est pas définie lorsqu'on accède au formulaire. Cette variable d'élément de formulaire contiendra le résultat de l'interprétation de l'élément de formulaire. La variable d'élément de formulaire d'un élément d'entrée s'appelle aussi une variable d'élément d'entrée, et elle contient la valeur collectée auprès de l'utilisateur. Une variable d'élément de formulaire peut recevoir un nom au moyen de l'attribut name ou peut rester anonyme, auquel cas il sera généré un nom interne.

Chaque élément de formulaire admet une condition de veille, laquelle régit le fait qu'un élément de formulaire puisse ou non être sélectionné par l'algorithme FIA. La condition de veille implicite vérifie simplement si la variable d'élément de formulaire a une valeur. Si c'est le cas, l'élément de formulaire ne sera pas visité.

Les éléments d'entrée reçoivent habituellement un nom, au contraire des éléments de commande. En général, les variables d'élément de formulaire n'ont pas de valeurs initiales et aucune autre condition de veille n'est définie. Parfois, cependant, un contrôle plus fin peut se révéler nécessaire. Un formulaire peut avoir une variable d'élément de formulaire dont la valeur est fixée initialement pour cacher un champ puis être effacée (par exemple, au moyen d'un élément clear) pour forcer la collecte du champ en question. Un autre champ peut avoir une condition de veille qui l'active seulement quand il n'a pas été collecté et après que deux autres champs ont été remplis. Un élément de bloc s'exécutera seulement quand certaines conditions seront vérifiées. On peut donc exercer un contrôle plus fin sur l'ordre dans lequel l'algorithme FIA sélectionnera et exécutera les éléments de formulaires. Toutefois, en général, on pourra construire beaucoup de dialogues sans avoir recours à un tel niveau de complexité.

En résumé, tous les éléments de formulaires admettent les attributs suivants :

2.1.4 Les formulaires dirigés

Le type de formulaire le plus simple et le plus commun est celui où les éléments de formulaire sont exécutés exactement une fois, en ordre séquentiel, pour mettre en œuvre une interaction dirigée par l'ordinateur. Voici un service météorologique répondant à ce type.

<?xml version="1.0" encoding="UTF-8"?> 
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd">
<form id="info_meteo">
 <block>Bienvenue sur ce service d'informations météorologiques !</block>
 <field name="pays">
  <prompt>Quel pays ?</prompt>
  <grammar src="pays.grxml"  type="application/srgs+xml"/>
  <catch event="help">
     Veuillez prononcer le nom du pays dont vous voulez connaître la météo.
  </catch>
 </field>
 <field name="ville">
  <prompt>Quelle ville ?</prompt>
  <grammar src="ville.grxml" type="application/srgs+xml"/>
  <catch event="help">
     Veuillez prononcer le nom de la ville dont vous voulez la météo.
  </catch>
 </field>
 <block>
  <submit next="/servlet/meteo" namelist="ville pays"/>
 </block>
</form>
</vxml>

Ce dialogue se déroule de manière séquentielle :

O (ordinateur) : Bienvenue sur ce service d'informations météorologiques ! Quel pays ?

H (humain) : Aide [ndt. help]

O : Veuillez prononcer le nom du pays dont vous voulez connaître la météo.

H : Islande

O : Quelle ville ?

H : Hùsavìk

O : Je n'ai pas compris ce que vous avez dit. Quelle ville ?

H : Akureyri

O : Les conditions à Akureyri, en Islande, sont ensoleillées et dégagées à 11h00, etc.

La première itération de l'algorithme FIA sélectionne le premier élément block, car sa variable d'élément de formulaire (cachée) n'est pas définie au départ. Ce bloc produit l'invite principale et la valeur de sa variable d'élément de formulaire est fixée à "true". À la deuxième itération, le premier élément block est sauté car sa valeur d'élément de formulaire est maintenant définie et le champ pays est sélectionné puisque l'état de la variable de dialogue n'est pas définie. Ce champ invite l'utilisateur à indiquer le pays puis assigne la réponse à la variable. On trouvera une description détaillée du remplissage des variables d'élément de formulaire depuis une grammaire de niveau champ dans le chapitre 3.1.6. La troisième itération du formulaire invite à remplir le champ ville pour le collecter ensuite. La quatrième itération exécute l'élément block final et effectue une transition vers une autre adresse URI.

Chaque champ de cet exemple produit une invite dans un certain ordre afin d'obtenir une réponse, indique une grammaire définissant ce qu'il faut écouter et comporte un gestionnaire d'événement pour l'événement help. L'événement help est suscité dès que l'utilisateur demande une assistance. Le gestionnaire d'événement help capture ces événements et fait une invite plus détaillée.

Voici un second formulaire dirigé, qui invite à donner des informations de carte de crédit :

<?xml version="1.0" encoding="UTF-8"?> 
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd">
<form id="obtenir_info_carte">
 <block>Nous avons maintenant besoin du type de votre
    carte de crédit, de son numéro et de sa
    date d'expiration.</block>
 <field name="type_carte">
  <prompt count="1">Quel est le type de votre
   carte de crédit ?</prompt>
  <prompt count="2">Type de carte ?</prompt>
  <!-- Ceci est une grammaire intégrée. -->
  <grammar type="application/srgs+xml" root="r2" version="1.0">
    <rule id="r2" scope="public">
       <one-of>
       <item>visa</item>
       <item>master <item repeat="0-1">card</item></item>
       <item>amex</item>
       <item>american express</item>
       </one-of>
    </rule>
  </grammar>
  <help> Veuillez dire Visa, MasterCard ou American Express.</help>
 </field>

 <field name="num_carte">
  <grammar type="application/srgs+xml" src="/grammars/digits.grxml"/>
  <prompt count="1">Quel est le numéro de votre carte ?</prompt>
  <prompt count="2">Numéro de carte ?</prompt>
  <catch event="help">
  <if cond="type_carte =='amex' || type_carte =='american express'">
       Veuillez dire ou bien saisir les 15 chiffres du numéro de votre carte.
     <else/>
       Veuillez dire ou bien saisir les 16 chiffres du numéro de votre carte.
     </if>
  </catch>
  <filled>
     <if cond="(type_carte == 'amex' || type_carte =='american express') 
          &amp;&amp; num_carte.length != 15">
       Les numéros des cartes American Express doivent avoir 15 chiffres.
       <clear namelist="num_carte"/>
       <throw event="nomatch"/>
     <elseif cond="type_carte != 'amex'
                &amp;&amp; type_carte !='american express'
                &amp;&amp; num_carte.length != 16"/>
       Les numéros des cartes MasterCard et Visa ont 16 chiffres.
       <clear namelist="num_carte"/>
       <throw event="nomatch"/>
     </if>
  </filled>
 </field>

 <field name="date_expiration">
   <grammar type="application/srgs+xml" src="/grammars/digits.grxml"/>
   <prompt count="1">Quelle est la date d'expiration de votre carte ?</prompt>
   <prompt count="2">Date d'expiration ?</prompt>
  <help>
     Veuillez dire ou saisir la date d'expiration, par exemple, un deux zéro un.
  </help>
  <filled>
     <!-- Validation de la date mmaa -->
     <var name="mm"/>
     <var name="i" expr="date_expiration.length"/>
     <if cond="i == 3">
       <assign name="mm" expr="date_expiration.substring(0,1)"/>
     <elseif cond="i == 4"/>
       <assign name="mm" expr="date_expiration.substring(0,2)"/>
     </if>
     <if cond="mm == '' || mm &lt; 1 || mm &gt; 12">
       <clear namelist="date_expiration"/>
       <throw event="nomatch"/>
     </if>
  </filled>
 </field>

 <field name="confirmer">
  <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
  <prompt>
      J'ai une carte <value expr="type_carte"/>, numéro
      <value expr="num_carte"/>, expirant le
      <value expr="date_expiration"/>.
      Est-ce exact ?
  </prompt>
  <filled>
    <if cond="confirmer">
      <submit next="placer_commande.asp"
        namelist="type_carte num_carte date_expiration"/>
    </if>
    <clear namelist="type_carte num_carte date_expiration confirmer"/>
  </filled>
 </field>
</form>
</vxml>

Remarquez que les alternatives grammaticales amex et american express renvoient des valeurs littérales qui demandent un traitement distinct dans les expressions conditionnelles. Le chapitre 3.1.5 décrit comment utiliser des rattachements sémantiques dans la grammaire pour ne renvoyer qu'une seule représentation de ces entrées.

Le dialogue pourrait prendre la tournure suivante :

O : Nous avons maintenant besoin du type de votre carte de crédit, de son numéro et de sa date d'expiration.

O : Quel est le type de votre carte de crédit ?

H : Discover

O : Je n'ai pas compris ce que vous avez dit (un message implicite propre à la platerforme).

O : Type de carte ? (on utilise la seconde invite cette fois-ci)

H : M.rd. ! (fort heureusement traitée comme aide par cette plateforme).

O : Veuillez dire Visa, MasterCard ou American Express.

H : Heuh... Amex (cette plateforme ignore le Heuh)

O : Quel est le numéro de votre carte ?

H : Un deux trois quatre ... attendez ...

O : Je n'ai pas compris ce que vous avez dit.

O : Numéro de carte ?

H: (utilisation de tonalités DTMF) 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 #

O : Quelle est la date d'expiration de votre carte ?

H : un deux zéro un

O : J'ai une carte Amex, numéro 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6, expirant le 1 2 0 1. Est-ce exact ?

H : Oui

Les champs sont les blocs de contruction principaux des formulaires. Un champ déclare une variable et définit les invites, les grammaires, les séquences DTMF, les messages d'assistance et les autres gestionnaires d'événements qui servent à l'obtenir. Chaque champ déclare une variable d'élément de formulaire VoiceXML dans la portée du dialogue du formulaire. Ces variables peuvent faire l'objet d'une soumission une fois le formulaire rempli ou être copiées dans d'autres variables.

Chaque champ possède ses propres grammaires vocales et/ou DTMF, définies explicitement au moyen d'éléments grammar ou bien implicitement au moyen d'un attribut type. L'attribut type peut s'utiliser pour les grammaires intégrées, comme les grammaires de type digits et boolean dans l'exemple.

Chaque champ peut définir une ou plusieurs invites. S'il n'y a qu'une invite, elle est répétée jusqu'à tant que l'utilisateur fournisse une valeur. S'il y a plusieurs invites, elles sont sélectionnées pour être reproduites selon l'algorithme de sélection des invites (voir le chapitre 4.1.6). L'attribut count sert à déterminer quelle invite utiliser à chaque itération. Dans l'exemple, les invites se raccourcissent. C'est ce qu'on appelle une incitation dégressive.

Les éléments <catch event="help"> sont des gestionnaires d'événement définissant ce qu'il faut faire lorsque l'utilisateur demande une assistance. Les messages d'assistance peuvent également être dégressifs. On peut les abréger ; les deux formes suivantes sont ainsi équivalentes :

<catch event="help">
 Veuillez dire visa, mastercard ou amex.
</catch>

<help>
 Veuillez dire visa, mastercard ou amex.
</help>

L'élément filled définit ce qu'il faut faire lorsque l'utilisateur fournit une entrée reconnue pour le champ. Une de ses utilisations consiste à définir des contraintes d'intégrité sur et en plus des vérifications faites par les grammaires, comme dans le champs date_expiration de l'exemple précédent.

2.1.5 Les formulaires à initiative mixte

Le chapitre précédent traitait de formulaires mettant en œuvre des conversations rigides conduites par l'ordinateur. Pour faire un formulaire à initiative mixte, où l'ordinateur et l'humain mènent tous deux la conversation, il faut que le formulaire ait une ou plusieurs grammaires de niveau formulaire. On peut écrire le dialogue de plusieurs façons. Un style de composition courant combine un élément initial, invitant à une réponse générale, et des éléments field, invitant à des renseignements particuliers. L'exemple ci-dessous en est une illustration. On peut obtenir un effet similaire avec des techiques plus complexes, comme utiliser l'attribut cond sur des éléments field.

Si un formulaire a des grammaires de niveau formulaire, alors :

• Ses éléments d'entrée peuvent être remplis dans n'importe quel ordre ;

• Plus d'un élément d'entrée peut être rempli en résultat d'une seule parole de l'utilisateur.

Seuls les éléments d'entrée (et non les éléments de commande) peuvent être remplis en résultat du filtrage d'une grammaire de niveau formulaire. Le remplissage des variables de champ lors de l'utilisation d'une grammaire de niveau formulaire est décrit dans le chapitre 3.1.6.

Également, les grammaires du formulaire peuvent être actives lorsque l'utilisateur se trouve dans d'autres dialogues. Si un document comporte deux formulaires, disons un formulaire pour une location de voiture et un autre pour une réservation d'hôtel, et que les deux formulaires ont des grammaires actives pour le document, alors un utilisateur pourrait répondre à une demande de renseignements concernant la réservation d'hôtel par des renseignements concernant la location de voiture et donc conduire l'ordinateur à discuter de location de voiture à la place. L'utilisateur peut avoir un échange avec n'importe quelle grammaire et, par conséquent, avoir des éléments d'entrée qui soient fixés et des actions qui soient entreprises en réponse.

Exemple. Voici une deuxième version du service d'informations météorologiques, montrant une initiative mixte. Dans un but d'illustration, on l'a amélioré avec de la publicité et avec une confirmation de la ville et du pays :

<?xml version="1.0" encoding="UTF-8"?> 
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd">
<form id="info_meteo">

 <grammar src="ville-et-pays.grxml" type="application/srgs+xml"/>

 <!-- L'appelant ne peut pas interrompre la publicité du jour. -->
 <block>
  <prompt bargein="false">
     Bienvenue sur ce service d'informations météorologiques !
     <audio src="http://www.pubs-en-ligne.example.com/wis.wav"/>
  </prompt>
 </block>

 <initial name="debut">
  <prompt>
     Quels sont la ville et le pays dont vous voulez connaître la météo ?
  </prompt>
  <help> 
    Veuiller prononcer le nom de la ville et celui du pays pour lesquels
    vous souhaitez un bulletin météorologique
  </help>
  <!-- Si l'utilisateur reste silencieux, faire une nouvelle invite puis
    essayer des invites dirigées. -->
  <noinput count="1"> <reprompt/></noinput>
  <noinput count="2"> <reprompt/>
    <assign name="debut" expr="true"/></noinput>
 </initial>

 <field name="pays">
  <prompt>Quel pays ?</prompt>
  <help>
    Veuillez prononcer le nom du pays dont vous voulez connaître la météo.
  </help>
 </field>

 <field name="ville">
  <prompt>Veuillez prononcer le nom de la ville située en <value expr="pays"/> 
                dont vous voulez connaître la météo.</prompt>
  <help>Veuillez prononcer le nom de la ville dont vous
    voulez connaître la météo.</help>
  <filled>
     <!-- La plupart de nos clients habitent Paris. -->
     <if cond="ville == 'Paris' &amp;&amp; pays == undefined">
       <assign name="pays" expr="'France'"/>
     </if>
  </filled>
 </field>

 <field name="continuer" modal="true">
  <grammar type="application/srgs+xml" src="/grammars/boolean"/>
  <prompt>Voulez-vous entendre le bulletin météorologique pour
    <value expr="ville"/>, <value expr="pays"/> ?
  </prompt>
  <filled>
     <if cond="continuer">
       <prompt bargein="false">
         <audio src="http://www.pubs-en-ligne.example.com/wis2.wav"/>
       </prompt>
       <submit next="/servlet/meteo" namelist="ville pays"/>
     </if>
     <clear namelist="debut ville pays continuer"/>
  </filled>
 </field>
</form>
</vxml>

Voici une transcription montrant les avantages présentés par ce type dialogue, même pour un utilisateur novice :

O : Bienvenue sur ce service d'informations météorologiques ! Achetez la mayonnaise de tante Louise !.

O : Quels sont la ville et le pays dont vous voulez connaître la météo ?

H : Heuh... France.

O : Veuillez prononcer le nom de la ville située en France dont vous voulez connaître la météo.

H : La Rochelle, s'il vous plaît.

O : Voulez-vous entendre le bulletin météorologique de La Rochelle, France ?

H : Non

O : Quels sont la ville et le pays dont vous voulez connaître la météo ?

H : Paris.

O : Voulez-vous entendre le bulletin météorologique pour Paris, France ?

H : Oui

O : N'oubliez pas d'acheter la mayonnaise de tante Louise ce soir !

O : Journée ensoleillée en général avec un maximum à 25°. Rafraîchissement en soirée...

La valeur de l'attribut modal du champ continuer est fixée à "true". Ce qui entraîne la désactivation de toutes les grammaires sauf celles définies dans l'élément de formulaire courant, de sorte que la seule grammaire active pendant la durée de ce champ est la grammaire intégrée de type boolean.

Un utilisateur expérimenté peut aller beaucoup plus vite (mais il toujours obligé d'écouter les publicités) :

O : Bienvenue sur ce service d'informations météorologiques ! Achetez la mayonnaise de tante Louise !

O : Quels sont...

H (interrompant) : Paris

O : Voulez-vous...

H (interrompant) : Oui

O : N'oubliez pas d'acheter la mayonnaise de tante Louise ce soir !

O : Journée ensoleillée en général avec un maximum à 25°. Rafraîchissement en soirée...

2.1.5.1 Le contrôle de l'ordre de collecte des champs

On peut personnaliser l'algorithme FIA de plusieurs manières. Une façon consiste à assigner une valeur à une variable d'élément de formulaire, de sorte que l'élément de formulaire ne soit pas sélectionné. Une autre façon est d'utiliser un élément clear pour fixer la valeur de la variable d'élément de formulaire à "undefined", ce qui force l'algorithme FIA à visiter de nouveau l'élément de formulaire.

Une autre méthode consiste à définir explicitement l'élément de formulaire suivant à visiter au moyen d'une déclaration <goto nextitem>. Ce qui force un transfert immédiat vers cet élément de formulaire, même si la valeur d'un quelconque attribut cond présent était évaluée à "false". Aucune variable ni condition ni compteur dans l'élément de formulaire visé ne sera réinitialisé. L'invite de l'élément de formulaire sera reproduite mais si elle a déjà été visitée. Si la déclaration <goto nextitem> apparaît au cours d'une action filled, le reste de l'action filled ainsi que toutes les éventuelles actions filled en cours seront sautés.

Voici un exemple de déclaration <goto nextitem> exécuté en réponse à l'événement exit :

<?xml version="1.0" encoding="UTF-8"?> 
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.w3.org/2001/vxml 
   http://www.w3.org/TR/voicexml20/vxml.xsd">
<link event="exit">
 <grammar type="application/srgs+xml" src="/grammars/exit.grxml"/>
</link>

<form id="sondage_2000_03_30">
  <catch event="exit">
    <reprompt/>
    <goto nextitem="confirmer_quitter"/>
  </catch>
  <block>
   <prompt>
     Bonjour, vous avez été tiré au sort afin de répondre à des questions
     critiques touchant à la politique étrangère des États-Unis.
   </prompt>
  </block>

  <field name="q1">
   <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
   <prompt>Êtes-vous d'accord avec la position du FMI concernant la
     privatisation de certains secteurs du ministère de l'agriculture
     du Burkina Faso ?</prompt>
  </field>

  <field name="q2">
    <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
    <prompt>Si ces privatisations avaient lieu, est-ce que ses effets
      bénéficieraient majoritairement à Ouagadougou et à Bobo-Dioulasso ?</prompt>
  </field>

  <field name="q3">
    <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
    <prompt>Êtes-vous d'accord que la production de sorgho et de millet
      pourraient augmenter de ce fait jusqu'à quatre pour cent l'an ?</prompt>
  </field>

  <block>
    <submit next="enregistrer" namelist="q1 q2 q3"/>
  </block>

  <field name="confirmer_quitter">
    <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
    <prompt>Vous avez choisi de ne pas répondre. Êtes-vous sûr
      de vouloir le faire, ce qui est susceptible d'affecter négativement
      la politique étrangère des États-Unis vis-à-vis de l'Afrique sub-saharienne
      pour les décennies à venir ?</prompt>
    <filled>
      <if cond="confirmer_quitter">
        C'est entendu, mais le Département d'État des États-Unis est mécontent.
        <exit/>
      <else/>
        Bon, reprenons où nous avons arrêté.
        <clear namelist="confirmer_quitter"/>
      </if>
    </filled>
    <catch event="noinput nomatch">
      <throw event="exit"/>
    </catch>
  </field>
</form>
</vxml>

Si l'utilisateur dit quitter [ndt. exit] à supposer que la grammaire ) en réponse à n'importe quelle question du sondage, un événement exit est suscité par la plateforme et capturé par le gestionnaire d'événement catch. Ce gestionnaire force le passage suivant au champ confirmer_quitter. Le champ confirmer_quitter n'aurait pas été visité au cours du remplissage normal du sondage parce que l'élément block précédent aurait passé le contrôle au script d'enregistrement.

2.1.6 L'algorithme d'interprétations des formulaires

Nous avons présenté l'algorithme d'interprétation des formulaires (FIA) à un niveau conceptuel. Dans ce chapitre, nous le décrivons de manière plus détaillée. Une description plus formelle est fournie dans l'annexe C.

2.1.6.1 La phase d'initialisation

Dès lors qu'on entre dans un formulaire, celui-ci est initialisé. Les variables du compteur d'invites interne (dans la portée du dialogue du formulaire) sont réinitialisées à "1". Chaque variable (les éléments var de niveau formulaire et les variables d'élément de formulaire) est initialisée, dans l'ordre du document, à la valeur "undefined" ou à la valeur de l'attribut expr concerné.

2.1.6.2 La boucle principale

La boucle principale de l'algorithme FIA comporte trois phases :

La phase de sélection: l'élément de formulaire suivant non rempli est sélectionné pour une visite.

La phase de collecte : l'élément de formulaire sélectionné est visité, ce qui produit une invite de l'utilisateur à une entrée, l'activation des grammaires appropriées puis l'attente et la collecte d'une entrée (comme une phrase prononcée ou l'appui de touches DTMF) ou d'un événement (comme une demande d'assistance ou un dépassement du délai d'entrée).

La phase de traitement : une entrée se traite en remplissant les éléments d'entrée et en exécutant les éléments field pour effectuer certaines actions telle qu'une validation d'entrée. Un événement se traite en exécutant le gestionnaire d'événement approprié pour le type d'événement en question.

Remarquez que l'algorithme FIA peut recevoir une entrée (un ensemble de couples de valeurs de grammaire attribut/attribut) qui aura été collectée pendant que l'utilisateur était dans l'interprétation d'un autre formulaire. Auquel cas, la première itération de la boucle principale saute les phases de sélection et de collecte pour aller directement à la phase de traitement avec cette entrée. Remarquez également que si une erreur survient au cours de la phase de sélection ou de collecte provoquant la génération d'un événement, alors l'événement est suscité et l'algorithme FIA se place directement dans la phase de traitement.

2.1.6.2.1 La phase de sélection

Le but de la phase de sélection consiste à sélectionner l'élément de formulaire suivant à visiter. Elle se déroule comme suit :

Si un élément goto, trouvé dans la phase de traitement de la dernière itération de la boucle principale, comportait la déclaration <goto nextitem>, alors l'élément de formulaire désigné est sélectionné.

Sinon, le premier élément de formulaire dont la valeur de la condition de veille est "false" est retenu pour une visite. Si une erreur survient pendant la vérification des conditions de veille, l'événement concerné est suscité, ce qui saute la phase de collecte, puis examiné dans la phase de traitement.

Si aucune condition de veille n'est fausse et que la dernière itération a parcouru le formulaire sans rencontrer un transfert de contrôle explicite, alors l'algorithme FIA produit implicitement une opération exit (de la même manière, si l'exécution se poursuit hors d'un formulaire, comme lorsqu'une erreur est générée hors d'un formulaire, sans qu'il y ait de transfert explicite du contrôle, alors l'interpréteur produira une opération exit implicite).

2.1.6.2.2 La phase de collecte

Le but de la phase de collecte consiste à recueillir une entrée ou un événement. L'élément de formulaire sélectionné est visité, ce qui produit des actions dépendant du type de l'élément de formulaire :

Si c'est un élément field, ou record, qui est visité, alors l'algorithme FIA sélectionne et met en file d'attente toutes les invites, selon le compteur d'invites de l'élément et les conditions des invites. Ensuite, il active et écoute la ou les grammaires de niveau champ et les éventuelles grammaires de niveau supérieur, et attend que l'élément se remplisse ou qu'un événement soit généré.

Si c'est un élément transfer qui est visité, alors les invites sont mises en file d'attente, selon le compteur d'invites de l'élément et les conditions des invites. Les grammaires des éléments sont activées. La file d'attente est exécutée avant que le transfert n'ait lieu.

Si c'est un élément subdialog, ou object, qui est visité, alors les invites sont mises en file d'attente, selon le compteur d'invites de l'élément et les conditions des invites. Les grammaires ne sont pas activées. Au contraire, le comportement de collecte des entrées est défini par le contexte exécutant du sous-dialogue ou de l'objet. La file d'attente n'est pas lue tant que le sous-dialogue ou l'objet n'ont pas été exécutés, mais elle devrait plutôt l'être au cours de la collecte d'entrées suivante.