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.

Si c'est un élément initial qui est visité, alors l'algorithme FIA sélectionne et met en file d'attente les invites, selon le compteur d'invites de l'élément initial et les conditions des invites. Il écoute ensuite la ou les grammaires de niveau formulaire et les éventuelles grammaires actives de niveau supérieur. Il attend enfin la reconnaissance par une grammaire ou un événement.

Un élément block sera visité en fixant la valeur de sa variable d'élement de formulaire à "true" puis en évaluant son contenu et enfin en ignorant la phase de traitement. Aucune entrée n'est collectée et l'itération suivante de la boucle principale de l'algorithme FIA est engagée.

2.1.6.2.3 La phase de traitement

Le but de la phase de traitement consiste à traiter l'entrée ou l'événement collectés au cours des phases précédentes, comme suit :

• Si un événement s'est produit (tels qu'une non-entrée ou un raccrochage), alors l'élément catch applicable est identifié puis exécuté. La sélection de l'élément catch applicable commence dans la portée de l'élément de forme courant puis se poursuit vers l'extérieur dans les portées des dialogues englobants. Cela peut entraîner l'interruption de l'algorithme FIA (par exemple, s'il effectue une transition vers un dialogue ou un document différents ou s'il exécute un élément exit) ou son basculement dans l'itération suivante de la boucle principale (par exemple, lorsque le gestionnaire d'événement help implicite est exécuté).
• Si une entrée est filtrée par une grammaire définie par un élément link, alors la transition vers le lien est exécutée ou son événement est suscité. Si l'élément link suscite un événement, celui-ci est traité dans le contexte de l'élément de formulaire courant (par exemple, initial, field, transfer, et ainsi de suite).
• Si une entrée est filtrée par une grammaire dans un formulaire autre que celui courant, alors l'algorithme FIA se termine, l'autre formulaire est initialisé et l'interprétation de ce formulaire commence avec cette entrée dans sa phase de traitement.

Si une entrée est filtrée par une grammaire dans ce formulaire, alors :

• Le résultat sémantique issu de la grammaire est relié à une ou plusieurs variables d'élément de formulaire, comme décrit dans le chapitre 3.1.6.
• Les actions filled déclenchées par ces assignations sont identifiées, comme décrit dans le chapitre 2.4.
• Chaque action filled identifiée est exécutée dans l'ordre du document. Si des éléments submit, disconnect, exit, return, goto ou throw sont rencontrés, alors les éléments filled restants ne sont pas exécutés et l'algorithme FIA soit se termine, soit poursuit dans l'itération suivante de la boucle principale. Un élément reprompt ne termine pas l'algorithme FIA (le nom suggère en effet une action), mais place plutôt un drapeau qui affecte le traitement des invites dans l'itération suivante de l'algorithme FIA. Si un événement est sucité dans la portée d'un élément filled, alors la sélection du gestionnaire d'événement commence dans la portée de l'élément filled en question, ce qui pourrait être celle d'un élément de formulaire ou du formulaire lui-même, puis se poursuit vers l'extérieur dans les portées des dialogues englobants.

Après achèvement de la phase de traitement, l'interprétation se poursuit en revenant à la phase de sélection.

On trouvera un algorithme d'interprétation des formulaires plus détaillé dans l'annexe C.

2.2 Les menus

Un menu est un raccourci syntaxique commode pour un formulaire ; il contient un seul champ anonyme qui invite l'utilisateur à faire un choix et il effectue une transition vers divers points en fonction de ce choix. Tout comme un formulaire régulier, sa grammaire peut avoir une portée fixée de façon à être active lorsque l'utilisateur exécute un autre dialogue. Le menu suivant offre trois choix à l'utilisateur :

<?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">
<menu>
  <prompt>
    Bienvenue à la maison. Dis ton choix parmi : <enumerate/>
  </prompt>
  <choice next="http://www.sports.example.com/vxml/debut.vxml">
     Sports
  </choice>
  <choice next="http://www.meteo.example.com/intro.vxml">
     Météo
  </choice>
  <choice next="http://www.astronomie.example.com/voice/astrojournal.vxml">
     Le journal d'astrophysique de l'astronome
  </choice>
  <noinput>Veux-tu dire ton choix parmi <enumerate/></noinput>
</menu>
</vxml>

Ce dialogue pourrait se dérouler comme suit :

O : Bienvenue à la maison. Dis ton choix parmi : sports, météo, le journal d'astrophysique de l'astronome.

H : Astrologie.

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

O : Bienvenue à la maison. Dis ton choix parmi : sports, météo, le journal d'astrophysique de l'astronome.

H : sports.

O : (poursuit vers http://www.sports.example.com/vxml/debut.vxml)

2.2.1 L'élément menu

Cet élément identifie le menu et détermine la portée de ses grammaires. Les attributs de l'élément menu sont :

2.2.2 L'élément choice

L'élément choice a plusieurs usages  :

• Il peut définir une grammaire vocale au moyen d'un élément grammar ou bien la générer automatiquement selon le processus décrit dans le chapitre 2.2.5.

• Il peut définir une grammaire DTMF, comme expliqué dans le chapitre 2.2.3.

• Son contenu peut servir à former la chaîne de l'invite de l'élément enumerate, comme décrit dans le chapitre 2.2.4.

• Il définit l'événement qu'il faut susciter ou bien l'adresse URI où aller lorsque le choix est sélectionné.

Les attributs de l'élément choice sont :

On doit définir exactement un seul d'entre les attributs next, expr, event ou eventexpr, sinon un événement error.badfetch est suscité. On peut indiquer exactement un seul d'entre les attributs message ou messageexpr, sinon un événement error.badfetch est suscité.

Si un élément grammar est défini dans un élément choice, alors la grammaire externe sera utilisée au lieu d'une grammaire générée automatiquement. Cela permet au développeur de contrôler précisément la grammaire associée à l'élément choice, par exemple :

<?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">
<menu>
  <choice next="http://www.sports.example.com/vxml/debut.vxml">
    <grammar src="sports.grxml" type="application/srgs+xml"/>
    Sports
  </choice>
  <choice next="http://www.meteo.example.com/intro.vxml">
   <grammar src="meteo.grxml" type="application/srgs+xml"/>
   Météo
  </choice>
  <choice next="http://www.astronomie.example.com/voice/astrojournal.vxml">
   <grammar src="astrojournal.grxml" type="application/srgs+xml"/>
   Le journal d'astrophysique de l'astronome
  </choice>
</menu>
</vxml>

2.2.3 Les tonalités DTMF dans les menus

Les menus peuvent dépendre seulement de la voix, seulement des tonalités DTMF ou bien d'une combinaison des deux en plaçant un élément property dans l'élément menu. Voici un menu uniquement DTMF, chacun des choix recevant une séquence DTMF explicite par le biais d'un attribut dtmf :

<?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">
<menu>
  <property name="mode_entree" value="dtmf"/>
  <prompt>
   Pour les sports : tapez 1, pour la météo : tapez 2, pour
   le journal d'astrophysique de l'astronome : tapez 3.
  </prompt>
  <choice dtmf="1" next="http://www.sports.example.com/vxml/debut.vxml"/>
  <choice dtmf="2" next="http://www.meteo.example.com/intro.vxml"/>
  <choice dtmf="3" next="http://www.astronomie.example.com/astrojournal.vxml"/>
</menu>
</vxml>

On peut, autrement, fixer la valeur de l'attribut dtmf de l'élément menu à "true" afin d'assigner des chiffres DTMF séquentiels à chacun des neuf premiers choix, pour autant que ceux-ci n'aient pas défini leur propre séquence DTMF : le premier choix ayant une valeur DTMF "1", et ainsi de suite :

<?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">
<menu dtmf="true">
  <property name="mode_entree" value="dtmf"/>
  <prompt>
   Pour les sports : tapez 1, pour la météo : tapez 2, pour
   le journal d'astrophysique de l'astronome : tapez 3.
  </prompt>
  <choice next="http://www.sports.example.com/vxml/debut.vxml"/>
  <choice next="http://www.meteo.example.com/intro.vxml"/>
  <choice dtmf="0" next="#operateur"/>
  <choice next="http://www.astronomie.example.com/voice/astrojournal.vxml"/>
</menu>
</vxml>

2.2.4 L'élément enumerate

L'élément enumerate est une description, générée automatiquement, des choix disponibles pour l'utilisateur. Il définit un modèle lequel s'applique à chacun des choix dans l'ordre où ceux-ci apparaissent dans le menu. En l'absence d'un contenu, c'est un modèle implicite listant tous les choix et déterminé par le contexte d'interprétation qui est utilisé. En présence d'un contenu, c'est alors le contenu qui définit le modèle. Cette définition peut faire appel à deux variables spéciales : _prompt qui représente l'invite du choix et _dtmf qui correspond à une représentation normalisée (c'est-à-dire, un seul blanc entre les atomes DTMF) de la séquence DTMF assignée au choix (remarquez que, si aucune séquence DTMF n'est assignée à l'élément choice ou si une grammaire est définie dans l'élément choice, alors la variable _dtmf reçoit la valeur ECMAScript "undefined"). Par exemple, récrivons le menu ainsi :

<?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">
<menu dtmf="true">
  <prompt>
    Bienvenue à la maison.
    <enumerate>
     Pour <value expr="_prompt"/>, tape <value
     expr="_dtmf"/>.
   </enumerate>
   </prompt>
   <choice next="http://www.sports.example.com/vxml/debut.vxml">
      les sports </choice>
   <choice next="http://www.meteo.example.com/intro.vxml">
      la météo </choice>
   <choice next="http://www.astronomie.example.com/voice/astrojournal.vxml">
      le journal d'astrophysique de l'astronome
   </choice>
</menu>
</vxml>

L'invite du menu serait alors :

O : Bienvenue à la maison. Pour les sports, tape 1. Pour la météo, tape 2. Pour le journal d'astrophysique de l'astronome, tape 3.

L'élément enumerate peut servir dans les invites et dans les éléments catch associés aux éléments menu et field contenant des éléments option, comme expliqué dans le chapitre 2.3.1.3. Un événement error.semantic est suscité si l'élément enumerate est utilisé ailleurs (par exemple, un élément enumerate dans un autre élément enumerate).

2.2.5 La génération des grammaires

Toute phrase de choix définit un ensemble de mots et de phrases à écouter. Une phrase de choix se construit à partir des données de type PCDATA des éléments contenus directement ou indirectement dans un élément choice d'un élément menu ou bien dans un élément option d'un élément field.

Si la valeur de l'attribut accept est "exact", alors l'utilisateur doit dire les mots de la phrase entière dans le même ordre que celui où ils apparaissent dans la phrase de choix.

Si la valeur de l'attribut accept est "approximate", alors le choix est susceptible d'être retenu quand l'utilisateur prononce une sous-phrase de l'expression. Par exemple, en réponse à l'invite Le journal d'astrophysique de l'astronome, l'utilisateur pourrait dire astronome, astrophysique, le journal de l'astronome, le journal d'astrophysique, et ainsi de suite. La grammaire correspondante peut dépendre de la langue et de la plateforme employées.

Comme exemple d'utilisation des valeurs "exact" ou "approximate" dans différents choix :

<?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">
<menu accept="approximate">
  <choice next="http://www.astronomie.example.com/voice/astrojournal.vxml"> 
   Le journal d'astrophysique de l'astronome </choice>
  <choice accept="exact"
  next="http://www.physiquehebdo.example.com/voice/example.vxml"> 
   L'hebdo de la physique </choice>
  <choice accept="exact"
  next="http://www.gazette-des-particules.example.com/voice/example.vxml"> 
  La gazette des particules </choice>
  <choice next="http://www.astrojour.example.com/voice/example.vxml"> 
  Astronomie du jour </choice>
</menu>
</vxml>

Puisque le premier élément choice définit une valeur "approximate", l'utilisateur peut dire une sous-phrase pour le choisir ; par exemple, dire astronome ou journal d'astrophysique. Par contre, les deuxième et troisième éléments définissant une valeur "exact", seule une phrase complète sera avérée : L'hebdo de la physique et La gazette des particules.

2.2.6 Le modèle d'interprétation

Un menu se comporte comme un formulaire ayant un seul champ qui endosse tous les rôles. Les invites du menu deviennent des invites du champ. Les gestionnaires d'événement du menu deviennent des gestionnaires d'événement du champ. Les grammaires du menu deviennent des grammaires du formulaire. Comme pour les formulaires, les correspondances de grammaire dans les menus mettront à jour le tableau application.lastresult$. Ces variables sont décrites dans le chapitre 5.1.5. Les grammaires générées doivent toujours produire des résultats simples dont les valeurs d'interprétation et de prononciation sont identiques.

Au lancement du menu, les grammaires du menu sont construites et activées puis l'invite est jouée. Lorsque l'entrée d'utilisateur correspond à un choix, le contrôle se déplace vers une transition conformément à la valeur de l'attribut next, expr, event ou eventexpr de l'élément choice, seul l'un d'entre eux pouvant être défini. Si on définit un attribut event sans que son gestionnaire d'événement n'incite l'interpréteur à quitter ou à déplacer le contrôle, alors l'algorithme FIA effacera la variable d'élément de formulaire du champ anonyme du menu, entraînant une nouvelle exécution du menu.

2.3 Les éléments de formulaire

Un élément de formulaire est un sous-élément de l'élément form pouvant faire l'objet d'une visite au cours de l'interprétaton du formulaire. Ce sont les éléments field, block, initial, subdialog, object, record et transfer.

Tous les éléments de formulaire ont les caractéristiques suivantes :

• Ils ont une variable de résultat, définie par l'attribut name. Cette variable peut recevoir une valeur initiale par le biais d'un attribut expr.

• Ils ont une condition de veille définie par l'attribut cond. Un élément de formulaire sera visité s'il n'est pas rempli et que son attribut cond n'est pas défini ou que l'évaluation de sa valeur, après conversion en un booléen, donne "true".

Les éléments de formulaire se rangent en éléments d'entrée, lesquels définissent les variables d'élément d'entrée du formulaire, et en éléments de commande, lesquels facilitent la collecte des éléments d'entrée du formulaire. Les éléments d'entrée (field, subdialog, object, record et transfer) sont généralement susceptibles de contenir les éléments suivants :

• Des éléments filled qui comprennent certaines actions à exécuter après que la variable d'élément d'entrée résultante a été remplie.

• Des éléments property afin de définir les propriétés en vigueur pour cet élément d'entrée (l'élément de formulaire initial peut également contenir cet élément).

• Des éléments prompt afin de définir les invites à jouer lorsque ce élément est visité.

• Des éléments grammar afin de définir les entrées vocales et textuelles permises pour cet élément de formulaire (les éléments subdialog et object ne peuvent pas contenir cet élément).

• Des éléments et des abréviations de l'élément catch qui sont en vigueur pour cet élément d'entrée (l'élément de formulaire initial peut également contenir cet élément).

À chaque élément d'entrée est associé un ensemble de variables fictives. Les variables fictives servent à renvoyer des résultats provenant de l'exécution d'un élément d'entrée, outre la valeur stockée par l'attribut name. Par exemple, il peut se révéler utile de connaître le niveau de fiabilité obtenu en résultat de la reconnaissance d'une grammaire dans un élément field. L'appel d'une variable fictive prend la forme nom$.varfictive, où nom représente la valeur de l'attribut name de l'élément de formulaire et varfictive le nom d'une variable fictive particulière. Les variables fictives sont inscriptibles et elles peuvent être modifiées par l'application. Par exemple, l'élément field renvoie une variable fictive confidence qui donne un indice de fiabilité. L'exemple ci-dessous illustre comment utiliser cette variable fictive.

<?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_pays">
<field name="pays">
  <prompt> Veuillez dire le nom d'un pays. </prompt>
  <grammar src="http://mesgrammaires.example.com/payss.gram"
              type="application/srgs"/>
  <filled>
    <if cond="pays$.confidence &lt; 0.4">
      <throw event="nomatch"/>
    </if>
  </filled>
</field>
</form>
</vxml>

Dans l'exemple, la fiabilité du résultat fait l'objet d'un examen : le résultat est rejeté si l'indice de fiabilité est trop faible.

2.3.1 L'élément field

Un champ définit un élément d'entrée qu'il faut recueillir de l'utilisateur. Les attributs de l'élément field sont :

On donne les variables fictives d'un élément field nommé nom dans le tableau 10. Les valeurs des variables fictives utterance, inputmode et interpretation doivent être les mêmes que celles dans le tableau application.lastresult$ (voir le chapitre 5.1.5).

2.3.1.1. Les champs utilisant des grammaires explicites

On peut définir les grammaires explicitement via une adresse URI absolue ou bien relative :

<field name="parfum">
  <prompt>Quelle est votre glace favorite ?</prompt>
  <grammar src="../grammaires/glace.grxml"
           type="application/srgs+xml"/>
</field>

On peut définir les grammaires directement, par exemple, avec un grammaire ABNF du W3C :

<field name="parfum">
  <prompt>Quel est votre parfum favori?</prompt>
  <help>Dites l'un entre vanille, chocolat ou fraise.</help>
  <grammar mode="voice" type="application/srgs">
   #ABNF 1.0;
   $options = vanille | chocolat | fraise
  </grammar>
</field>

Si on définit à la fois l'attribut src d'un élément grammar et une grammaire directe, alors un événement error.badfetch est suscité.

2.3.1.2. Les grammaires explicites et les ressources intégrées propres à une plateforme

La prise en compte par une plateforme de ressources intégrées telles que les grammaires vocales, les grammaires DTMF et les fichiers sons est optionnelle. Ces ressources sont accessibles au moyen d'adresses URI propres à la plateforme, tel que, par exemple, http://localhost:5000/grammar/boolean, ou bien de systèmes propres à la plateforme tel que le système couramment employé builtin comme dans builtin:grammar/boolean.

Si une plateforme permet l'accès à des ressources intégrées, alors elle devrait également permettre l'accès aux grammaires intégrées fondamentales (voir l'annexe P) ; par exemple :

<grammar src="builtin:grammar/boolean"/>
<grammar src="builtin:dtmf/boolean"/>

Le premier élément grammar appelle la grammaire vocale intégrée de type boolean et le second la grammaire DTMF intégrée de type boolean.

Par définition, la déclaration :

<field type="type-intégré">
   <prompt>Invite pour une grammaire intégrée</prompt>
</field>

Celle-ci est équivalente à la déclaration suivante des grammaires intégrées propres à une plateforme :

<field>
   <grammar src="builtin:grammar/type-intégré"/>
   <grammar src="builtin:dtmf/type-intégré"/> 
   <prompt>Invite pour une grammaire intégrée</prompt>
</field>

Où la valeur type-intégré représente l'un des types intégrés fondamentaux de champ (c'est-à-dire, boolean, date, etc.).

En outre, on peut utiliser les systèmes d'adresse URI intégrés propres à une plateforme pour accéder aux grammaires reconnues par des contextes d'interprétation particuliers. On recommande pour les noms des grammaires intégrées propres à une plateforme qu'ils commencent par la chaîne x- ; cet espace de nommage ne sera pas utilisé dans les versions futures de la norme.

Exemples de grammaires intégrées propres à une plateforme :

<grammar src="builtin:grammar/x-type-intégré"/>
<grammar src="builtin:dtmf/x-type-intégré"/>

2.3.1.3. Les champs avec des listes d'options

Lorsque l'on a simplement besoin d'un ensemble d'alternatives pour définir les valeurs d'entrée légales d'un champ, il peut se révéler plus commode d'utiliser une liste d'options qu'une grammaire. On représente une liste d'options par un ensemble d'éléments option compris dans un élément field. Chaque élément option contient des données de type PCDATA, lesquelles servent à générer une grammaire vocale. Cette méthode de génération de grammaire suit celle décrite pour l'élément choice dans le chapitre 2.2.5. On peut se servir d'attributs afin de définir une séquence DTMF pour chaque option et afin de contrôler la valeur assignée à la variable d'élément de formulaire du champ. Lors du choix d'une option, l'attribut value détermine la valeur interpretation pour la variable fictive du champ et pour la variable du tableau application.lastresult$.

Le champ suivant propose trois possibilités à l'utilisateur et assigne la valeur de l'attribut value de l'option sélectionnée à la variable plat_principal :

<field name="plat_principal">
  <prompt>
      Veuillez sélectionner une entrée. Aujourd'hui, nous vous proposons <enumerate/>
  </prompt>

  <option dtmf="1" value="poisson"> de l'espadon </option>
  <option dtmf="2" value="viande"> du rôti de bœuf </option>
  <option dtmf="3" value="volaille"> des cuisses de poulet </option>

  <filled>
    <submit next="/cgi-bin/platprincipal.cgi"
        method="post" namelist="plat_principal"/>
  </filled>
</field>

Cela pourrait donner la conversation suivante :

O : Veuillez sélectionner une entrée. Aujourd'hui nous vous proposons de l'espadon ; du rôti de bœuf ; des cuisses de poulet.

H : cuisses de poulet

O : (assigne la valeur volaille à la variable plat_principal puis soumet la requête plat_principal=volaille au script platprincipal.cgi)

L'exemple suivant montre un usage correct et un usage erronné de l'élément enumerate dans un élément catch d'un formulaire dont plusieurs champs contiennent des éléments option :

<?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>
  <block>
    Nous avons besoin de quelques précisions pour prendre votre commande.
  </block>
  <field name="couleur">
    <prompt>Quelle couleur ?</prompt>
    <option>rouge</option>
    <option>bleu</option>
    <option>vert</option>
  </field>
  <field name="taille">
    <prompt>Quelle taille ?</prompt>
    <option>petit</option>
    <option>moyen</option>
    <option>grand</option>
  </field>
  <field name="quantite">
    <grammar type="application/srgs+xml" src="/grammars/number.grxml"/>
    <prompt>Combien ?</prompt>
  </field>
  <block>
    Merci. Votre commande suit son cours.
    <submit next="details.cgi" namelist="couleur taille quantite"/>
  </block>
  <catch event="help nomatch">
    Voici les options possibles : <enumerate/>.
  </catch>
</form>
</vxml>

Le déroulement du dialogue pourrait être celui-ci :

O : Nous avons besoin de quelques précisions pour prendre votre commande. Quelle couleur ?

H : aide (lance l'événement help capturé par l'élément catch de niveau formulaire).

O : Voici les options possibles : rouge, bleu, vert.

H : rouge.

O : Quelle taille ?

H : 7 (lance l'événement nomatch capturé par l'élément catch de niveau formulaire).

O : Voici les options possibles : petit, moyen, grand.

H : petit.

Dans la succession d'étapes précédente, l'élément enumerate dans l'élément catch de niveau formulaire avait quelque chose à énumérer : les éléments option dans les champs couleur et taille. Au contraire, l'élément field suivant est différent :

O : Combien ?

H : beaucoup (lance un événement nomatch capturé par l'élément catch de niveau formulaire).

L'utilisation de l'élément enumerate par l'élément catch de niveau formulaire entraîne le déclenchement d'un événement error.semantic parce que le champ quantite ne contient aucun élément option susceptible d'énumération.

Une solution serait de rajouter un élément catch de niveau champ au champ quantite :

<catch event="help nomatch">
       Veuillez indiquer le nombre d'articles à commander.
</catch>

L'événement nomatch serait alors capturé localement, aboutissant probablement à la fin d'échange suivante :

O : Veuillez indiquer le nombre d'articles à commander.

H : 50

O : Merci. Votre commande suit son cours.

L'élément enumerate est également abordé dans le chapitre 2.2.4.

Les attributs de l'élément option sont :

L'utilisation d'éléments option n'empêche pas celle d'éléments grammar. Le résultat correspondrait à l'une ou l'autre grammaire et non à la présence de deux éléments grammar dans le même élément field représentant une disjonction de choix.

2.3.2 L'élément block

C'est un élément de formulaire avec un contenu exécutable lequel est exécuté si la valeur de la variable d'élément de formulaire de l'élément block est "undefined" et si la valeur de son attribut cond, le cas échéant, est évaluée à "true".

<block>
   Bienvenue chez Les sept nains, votre magasin de décorations pour le jardin.
</block>

La valeur de la variable d'élément de formulaire est fixée automatiquement à "true" juste avant que le bloc ne soit visité. C'est pourquoi, les blocs ne sont en général exécutés qu'une seule fois par invocation du formulaire.

Parfois, on peut avoir besoin d'un contrôle accru des blocs. Pour ce faire, on peut nommer la variable d'élément de formulaire et en fixer ou effacer la valeur afin de contrôler l'exécution de l'élément block. Cette variable se déclare dans la portée du dialogue du formulaire.

Les attributs de l'élément block comprennent :

2.3.3. L'élément initial

Dans un formulaire à initiative mixte typique, un élément initial est visité lorsque l'utilisateur fait l'objet d'une invite initiale pour des renseignements concernant l'ensemble du formulaire et que l'utilisateur ne se trouve pas encore dans le mode dirigé selon lequel chaque champ est visité individuellement. Comme les éléments d'entrée, il dispose d'invites, d'éléments catch et de compteurs d'événements. Par contre, il ne comporte aucune grammaire ni action filled. Par exemple :

<?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_villes_depart_et_arrivee">
   <grammar src="http://www.directions.example.com/grammars/depuis_vers.grxml" 
       type="application/srgs+xml"/>
   <block>
       Bienvenue sur Directions de conduite par téléphone.
   </block>
   <initial name="sauter_init">
     <prompt>
       D'où partez vous et où voulez-vous aller?
     </prompt>
     <nomatch count="1">
        Veuillez dire, par exemple, de Bruxelles, en Belgique, à Lausanne, en Suisse.
     </nomatch>
     <nomatch count="2">
        Désolé mais je ne comprends toujours pas.
        Je vous demanderai de fournir les renseignements un par un.
        <assign name="sauter_init" expr="true"/>
        <reprompt/>
     </nomatch>
   </initial>
   <field name="ville_depart">
     <grammar src="http://www.directions.example.com/grammaires/ville.grxml" 
              type="application/srgs+xml"/>
     <prompt>De quelle ville partez-vous ?</prompt>
   </field>
   <field name="ville_arrivee">
     <grammar src="http://www.directions.example.com/grammaires/ville.grxml" 
              type="application/srgs+xml"/>
     <prompt>Quelle est la ville d'arrivée ?</prompt>
   </field>
</form>
</vxml>

Si un événement se produit pendant la visite d'un élément initial, alors un de ses gestionnaires d'événement s'exécute. Comme pour les autres éléments de formulaire, l'élément initial reste éligible pour une visite tant que la valeur de sa variable d'élément de formulaire est "undefined" et que son attribut cond vaut "true". Si une ou plusieurs des variables d'élément de formulaire sont fixées par une entrée d'utilisateur, alors toutes les valeurs des variables d'élément de formulaire de l'élément initial sont fixées à "true", avant l'exécution d'une quelconque action filled.

On peut manipuler explicitement la variable d'élément de formulaire d'un élément initial afin d'inactiver ou de rétablir son éligibilité vis-à-vis de l'algorithme FIA. Par exemple, dans le programme précédent, la valeur de la variable d'élément de formulaire de l'élément initial est fixée lors du second événement nomatch. Cela a pour effet de détourner l'algorithme FIA de l'élément initial vers l'élément de formulaire suivant, à savoir un élément field qui produit explicitement une invite pour la ville de départ. On pourrait tout aussi bien effacer la valeur de la variable d'élément de formulaire de l'élément initial, de sorte que celui-ci devienne à nouveau sélectionnable par l'algorithme FIA.

On peut définir plusieurs éléments initial dans le même formulaire. Une fois dans le formulaire, seul le premier élément initial, dans l'ordre du document, qui est éligible en vertu de son attribut cond, sera visité. Une fois la première variable d'élément de formulaire remplie, toutes les variables d'élément de formulaire des éléments initial reçoivent la valeur "true", ceux-ci ne seront dès lors plus visités. L'effacement explicite des variables des éléments initial permet leur réutilisation et même la sélection d'un élément initial différent lors des itérations suivantes de l'algorithme FIA.

L'attribut cond peut aussi servir à sélectionner quel élément initial utiliser dans une itération donnée. Une application pourrait aligner plusieurs éléments initial et les marquer avec leur attribut cond en vue d'une utilisation particulière selon les circonstances, par exemple, l'attribut cond étant utilisé pour tester la nature d'un mode d'exploitation, pour utilisateur expérimenté ou bien pour utilisateur novice, et les éléments initial ne servant que dans le mode avancé. En outre, si le premier élément initial dans l'ordre du document définissait une valeur improbable pour son attribut cond, il ne serait alors jamais exécuté. Si les valeurs des attributs cond de tous les éléments initial empêchaient leur sélection, alors aucun ne serait exécuté.

Les règles de portée des grammaires s'appliquent pour la visite d'un élément initial, comme décrit dans le chapitre 3.1.3.. En particulier, aucune grammaire attachée à un élément field n'est active.

Remarque : L'assignation explicite de valeurs à des variables d'élément d'entrée n'affecte pas la valeur de la variable d'élément de formulaire d'un élément initial.

Les attributs de l'élément initial comprennent :

2.3.4 L'élément subdialog

Les sous-dialogues représentent un mécanisme permettant la réutilisation de dialogues communs et la constitution de librairies d'applications réutilisables.

L'élément subdialog invoque un dialogue appelé (c'est le sous-dialogue) identifié par les attributs src ou srcexpr dans le dialogue appelant. Le sous-dialogue s'exécute dans un nouveau contexte d'exécution qui comprend toutes les déclarations et informations d'état du sous-dialogue, le document du sous-dialogue et (le cas échéant) la racine de l'application du sous-dialogue, les compteurs étant réinitialisés et les variables initialisées. Le sous-dialogue se poursuit jusqu'à l'exécution d'un élément return ou bien exit, ou jusqu'à ce qu'il ne reste plus aucun élément de formulaire susceptible d'une sélection par l'algorithme FIA (ce qui équivaut à un élément exit). Un élément return entraîne le retour du contrôle et de données au dialogue appelant (voir le (chapitre 5.3.10). Lorsque le sous-dialogue revient, son contexte d'exécution est détruit et l'exécution reprend alors dans le dialogue appelant, les éventuels éléments filled étant remplis de manière appropriée.

Le contexte du sous-dialogue et celui du dialogue appelant sont indépendants, même si les dialogues se trouvent dans le même document. Les variables dans la chaîne des portées du dialogue appelant ne sont pas partagées avec le sous-dialogue appelé : il n'existe aucun partage des instances de variable entre les contextes d'exécution. Et, même quand le sous-dialogue est défini dans le même document que le dialogue appelant, le contexte d'exécution du sous-dialogue contiendra des instances de variables différentes. Lorsque le sous-dialogue et le dialogue appelant sont dans des documents différents tout en partageant le même document racine, leurs valeurs d'attribut root sont également des instances différentes. Toutes les liaisons de variables appliquées dans le contexte du sous-dialogue sont perdues au retour dans le contexte appelant.

Par contre, dans le contexte du sous-dialogue, les règles de portée normales des grammaires, des événements et des variables s'appliquent. Les grammaires actives d'un sous-dialogue comprennent les grammaires implicites définies par le contexte d'interprétation et les grammaires de portée convenable définies dans les éléments link, menu et form dans le document du sous-dialogue et son document racine. La gestion des événements et la liaison des variables suit également la hiérarchie normale des portées.

Dans une perspective de programmation, les sous-dialogues se comportent différemment des sous-routines dans la mesure où les contextes appelant et appelé sont indépendants. Alors qu'une sous-routine peut accéder à des instances de variables appartenant à la routine appelante, un sous-dialogue ne pourra pas accéder à la même instance de variable définie dans le dialogue appelant. De même, les sous-dialogues n'obéissent pas au modèle de percolation des événements trouvé dans des langages comme Java, pour lequel un événement suscité dans une méthode va remonter automatiquement au contexte appelant s'il n'est pas pris en charge dans le contexte appelé. Les événements suscités dans un sous-dialogue sont traités par les gestionnaires d'événement définis dans son contexte ; il ne peuvent être passés au contexte appelant que par un gestionnaire d'événement local renvoyant explicitement l'événement au contexte appelant (voir le chapitre 5.3.10).

Le sous-dialogue est désigné par l'adresse URI dans l'attribut src ou srcexpr de l'élément subdialog (voir le document [RFC2396]). Si cet appel d'adresse URI contient une adresse absolue ou relative, pouvant contenir une chaîne de requête, alors cette adresse URI est extraite et le sous-dialogue se trouvera dans le document résultant. Si l'élément subdialog comporte un attribut namelist, alors les variables composant sa valeur sont ajoutées à la chaîne de requête de l'adresse URI.

Si l'appel d'adresse URI contient seulement un fragment (c'est-à-dire, aucune adresse URI absolue ou relative) et s'il n'y a pas d'attribut namelist, alors aucune recherche n'a lieu : le sous-dialogue se trouve dans le document courant.

Le fragment d'un appel d'adresse URI indique, le cas échéant, le sous-dialogue à invoquer. En l'absence d'un fragment, le sous-dialogue invoqué est le premier dialogue lexical dans le document.

Si l'appel d'adresse URI n'est pas valide (c'est-à-dire quand le dialogue ou le document n'existent pas), un événement error.badfetch doit être suscité. Remarquez que, en ce qui concerne les erreurs qui se produisent pendant une transition de dialogue ou de document, la portée dans laquelle les erreurs sont censés être traitées est propre à la plateforme.

Les attributs de l'élément subdialog sont :

On doit définir exactement un seul attribut src ou bien srcexpr, sinon un événement error.badfetch est suscité.

L'élément subdialog peut contenir les éléments communs à tous les éléments de formulaires et aussi des éléments param. Les éléments param d'un élément subdialog définissent les paramètres à passer au sous-dialogue. Ces paramètres doivent être déclarés comme éléments var dans le formulaire exécuté comme sous-dialogue ou alors un événement error.semantic sera sucité. Lors de l'initialisation du sous-dialogue, les éléments var sont également initialisés, dans l'ordre du document, à la valeur indiquée par l'élément param dont le nom correspond. Les valeurs paramètres sont calculées en évaluant l'attribut expr de l'élément param dans le contexte de l'élément param. Un attribut expr dans l'élément var sera ignoré dans ce cas. Si aucun élément param ne correspond à un élément var, on utilise un attribut expr comme valeur par défaut, ou bien la variable prend la valeur "undefined" si l'attribut expr n'est pas défini, comme pour un élément form régulier.

Dans l'exemple suivant, on se sert de la date de naissance d'une personne pour valider son permis de conduire. L'attribut src de l'élément subdialog se rapporte à un formulaire dans le même document. On utilise l'élément param pour passer la valeur de la date de naissance au sous-dialogue.

<?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">
<!-- Un dialogue de formulaire qui appelle un sous-dialogue -->
<form>
  <subdialog name="resultat" src="#demander_permis_conduire">
   <param name="date_naissance" expr="'2000-02-10'"/>
   <filled>
     <submit next="http://monservice.example.com/cgi-bin/traiter"/>
   </filled>
  </subdialog>
</form>

<!-- Un sous-dialogue pour obtenir les permis de conduire -->
<form id="demander_permis_conduire">
  <var name="date_naissance"/>
  <field name="permis_conduire">
   <grammar src="http://grammarlib/grammaire_conduite.grxml"
      type="application/srgs+xml"/>
   <prompt> Veuillez indiquer le numéro de votre permis de conduire. </prompt>
   <filled>
     <if cond="permis_conduire_valide(permis_conduire,date_naissance)">
       <var name="statut" expr="true"/>
     <else/>
       <var name="statut" expr="false"/>
     </if>
     <return namelist="permis_conduire statut"/>
   </filled>
  </field>
</form>
</vxml>

La valeur du permis de conduire est renvoyée au dialogue appelant, accompagnée d'une variable de statut, afin d'indiquer si le permis est valide ou non.

Cet exemple illustre également la commodité avec laquelle on transmet des données au sous-dialogue afin d'y instancier des valeurs sans faire appel à un script côté serveur. On donne ci-dessous une autre solution avec un script.

Document avec un formulaire appelant un sous-dialogue

<?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>
   <field name="date_naissance">
     <grammar type="application/srgs+xml" src="/grammars/date.grxml"/>
     Quelle est votre date de naissance ?
   </field>
   <subdialog name="resultat"
          src="/cgi-bin/getlib#demanderpermisconduire"
          namelist="date_naissance">
     <filled>
       <submit next="http://monservice.example.com/cgi-bin/traiter"/>
     </filled>
   </subdialog>
  </form>
</vxml>

Document contenant le sous-dialogue (généré par /cgi-bin/getlib)

<?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="demander_permis_conduire">
    <var name="date_naissance" expr="'1980-02-10'"/>
    <!-- Généré par un script côté serveur -->
   <field name="permis_conduire">
     <grammar src="http://grammarlib/grammaire_conduite.grxml"
        type="application/srgs+xml"/>
     <prompt>
       Veuillez indiquer le numéro de votre permis de conduire.
     </prompt>
     <filled>
       <if cond="permis_conduire_valide(permis_conduire,date_naissance)">
         <var name="statut" expr="true"/>
       <else/>
         <var name="statut" expr="false"/>
       </if>
       <return namelist="permis_conduire statut"/>
     </filled>
   </field>
  </form>
</vxml>

Dans l'exemple précédent, un script côté serveur était chargé de générer le document et d'incorporer la valeur de la date de naissance.

On donne ensuite un dernier exemple qui montre la capture des informations générales d'une carte de crédit par un sous-dialogue. On définit tout d'abord le sous-dialogue dans un document séparé car on souhaite le réutiliser dans des applications différentes. Il renvoie un statut, le numéro de la carte de crédit et sa date d'expiration ; si une donnée est manquante, on renvoie le statut avec la valeur incomplet.

<?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">
   <!-- Exemple de sous-dialogue pour collecter les informations d'une carte de crédit. -->
   <!-- Le fichier se trouve à http://www.uncertaindomaine.example.com/ncc.vxml -->
   <form id="demander_cartecredit">
     <var name="statut" expr="'incomplet'"/>

     <field name="numero_carte">
       <prompt>
         Quel est le numéro de votre carte de crédit ?
       </prompt>
       <help>
         J'essaye d'obtenir le numéro de votre carte de crédit.
         <reprompt/>
       </help>
       <nomatch>
         <return namelist="statut"/>
       </nomatch>
       <grammar src="ncc.grxml" type="application/srgs+xml"/>
     </field>

     <field name="date_expiration">
       <grammar type="application/srgs+xml" src="/grammars/date.grxml"/>
       <prompt>
         Quelle est la date d'expiration de cette carte ?
       </prompt>
       <help>
         J'essaye d'obtenir la date d'expiration associée au numéro de carte de crédit
         que vous avez fourni.
         <reprompt/>
       </help>
       <nomatch>
         <return namelist="statut"/>
       </nomatch>
     </field>

     <block>
       <assign name="statut" expr="'resultat'"/>
       <return namelist="statut numero_carte date_expiration"/>
     </block>
   </form>
</vxml>

Voici maintenant une application qui présente un dialogue appelant. Elle demande le nom d'un logiciel et d'un système d'exploitation au travers d'un dialogue à initiative mixte puis sollicite les informations de la carte de crédit au moyen du sous-dialogue précédent.

<?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">
  <!-- Exemple de programme principal -->
  <!-- http://www.uncertaindomaine.example.com/principal.vxml -->
  <!-- on appelle le sous-dialogue ncc.vxml -->

  <!-- on suppose que c'est défini par un dialogue -->
  <var name="nom_utilisateur"/>

  <form id="acheter_logiciel">
    <var name="ncc"/>
    <var name="exp"/>
    <grammar src="achatlogiciel.grxml" type="application/srgs+xml"/>
    <initial name="debut">
      <prompt>
        Veuillez indiquer le logiciel que vous souhaitez acheter
        et le système d'exploitation sur lequel il doit tourner.
      </prompt>
      <noinput>
        <assign name="debut" expr="true"/>
      </noinput>
    </initial>

    <field name="logiciel">
      <prompt>
        Quel logiciel souhaitez-vous acheter ?
      </prompt>
    </field>

    <field name="systeme">
      <prompt>
        Sur quel système d'exploitation le logiciel doit-il tourner ?
      </prompt>
    </field>

    <subdialog name="resultats_cc"
        src="http://uncertaindomaine.example.com/ncc.vxml">
      <filled>
        <if cond="resultats_cc.statut=='incomplet'">
          Dans l'impossibilité d'obtenir les renseignements nécessaires au paiement,
          nous sommes au regret d'annuler cette commande.
          <exit/>
        <else/>
          <assign name="ncc" expr="resultats_cc.numero_carte"/>
          <assign name="exp" expr="resultats_cc.date_expiration"/>
        </if>
      </filled>
    </subdialog>

    <block>
      Nous allons maintenant traiter votre commande. Veuillez patienter.
      <submit next="www.uncertaindomaine.example.com/traiter_commande.asp"
              namelist="nom_utilisateur logiciel systeme ncc exp"/>
    </block>
  </form>
</vxml>

2.3.5. L'élément object

Une plateforme d'implémentation VoiceXML peut offrir, au travers de l'élément object, une fonctionnalité propre utilisable par une application VoiceXML. L'élément object utilise directement son propre contenu au cours de l'initialisation (par exemple, un sous-élément param) et de l'exécution. Par conséquent, on ne peut pas traiter le contenu d'un élément object comme un contenu alternatif. Notez que, à l'instar des autres éléments d'entrée, l'élément object peut produire des invites et comporter des éléments catch. Il peut également comprendre des actions filled.

Par exemple, on pourrait accéder à un objet pour la collecte des informations d'une carte de crédit, propre à une plateforme, de cette façon :

<object
    name="debit"
    classid="methode://carte-credit/recueillir_et_debiter"
    data="http://www.enregistrements.example.com/invites/credit/jesse.jar">
  <param name="montant" expr="document.amt"/>
  <param name="vendeur" expr="code_vendeur"/>
</object>

Dans cet exemple, l'élément param (voir le chapitre 6.4) sert à passer des paramètres à l'objet quand on l'invoque. Lorsque cet élément object est exécuté, il renvoie un objet ECMASCript comme valeur de sa variable d'élément de formulaire. L'élément block suivant présente les valeurs renvoyées par l'objet de carte de crédit :

<block>
   <prompt>
     La carte est de type <value expr="debit.carte"/>.
   </prompt>

   <prompt>
     Le numéro de la carte est <value expr="debit.num_carte"/>.
   </prompt>

   <prompt>
     La date d'expiration est <value expr="debit.date_expiration"/>.
   </prompt>

   <prompt>
     Le code d'approbation est <value expr="debit.code_approbation"/>.
   </prompt>

   <prompt>
     Le numéro de confirmation est <value expr="debit.num_confirmation"/>.
   </prompt>
</block>

Comme autre exemple, supposons qu'un plateforme ait une fonctionnalité selon laquelle l'utilisateur peut saisir des messages textuels arbitraires au moyen d'un clavier téléphonique.

<?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="recueillir_message_teleavertisseur">
  <object name="message"
      classid="builtin://entree-texte-clavier">
   <prompt>
     Tapez le message sur votre clavier une touche par lettre.
     Pour une espace, tapez étoile. Pour terminer, tapez dièse.
   </prompt>
  </object>

  <block>
    <assign name="document.message_teleavertisseur" expr="message.texte"/>
    <goto next="#confirmer_message_teleavertisseur"/>
  </block>
</form>
</vxml>

L'utilisateur est d'abord invité à laisser un message puis il le tape. L'élément block copie le message dans la variable document.message_teleavertisseur.

Les attributs de l'élément object comprennent :

Les implémentations ne sont pas obligées de fournir des objects spécifiques à la plateforme, mais elles doivent gérer l'élément object et susciter un événement error.unsupported.objectname si l'objet particulier propre à la plateforme n'est pas reconnu (remarquez que le objectname dans error.unsupported.objectname est une chaîne fixe, qu'on ne doit donc pas remplacer par le nom de l'objet non reconnu). Si une implémentation se comporte ainsi, alors on considère qu'elle gère l'élément object.

Il est du ressort de l'objet en question de déterminer la validité des noms ou valeurs des paramètres reçus. L'élément object suscite une erreur en cas d'invalidité. L'erreur est soit propre à l'objet, soit c'est l'une des erreurs normalisées listées dans le chapitre 5.2.6.

2.3.6. L'élément record

L'élément record est un élément d'entrée destiné à recueillir un enregistrement provenant de l'utilisateur. Une référence au son enregistré est stockée dans la variable d'élément d'entrée, lequel son peut être joué (en se servant de l'attribut expr sur un élément audio) ou bien envoyé à un serveur, comme le montre cet exemple :

<?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>
     <property name="bargein" value="true"/>
     <block>
       <prompt>
         Riley ne peut pas prendre votre appel.
       </prompt>
     </block>
     <record  name="msg" beep="true" maxtime="10s"
       finalsilence="4000ms" dtmfterm="true" type="audio/x-wav">
       <prompt timeout="5s">
         Laissez un message après le bip.
       </prompt>
       <noinput>
         Je n'ai rien entendu, veuillez recommencez.
       </noinput>
     </record>

     <field name="confirmer">
       <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
       <prompt>
          Voici votre message : <audio expr="msg"/>.
       </prompt>
       <prompt>
         Pour le valider, dites oui ; pour le supprimer, dites non.
       </prompt>
       <filled>
         <if cond="confirmer">
           <submit next="sauvegarde_message.pl" enctype="multipart/form-data"
               method="post" namelist="msg"/>
         </if>
         <clear/>
       </filled>
     </field>
   </form>
</vxml>

L'utilisateur est invité à laisser un message puis il l'enregistre. L'enregistrement se termine dans l'une des conditions suivantes : le délai de parole est écoulé, une touche DTMF est pressée, la durée d'enregistrement maximale est dépassée ou l'appelant raccroche. L'enregistrement est joué et, si l'utilisateur l'approuve, il est envoyé au serveur pour y être stocké au moyen de la méthode POST du protocole HTTP. Notez que, comme les autres éléments d'entrée, l'élément record peut avoir une grammaire, produire des invites et comporter des éléments catch. Il peut également comporter des actions filled.

Figure 7 : La temporisation des invites, d'un enregistrement sonore et d'une entrée DTMF

Lorsqu'un utilisateur raccroche en cours d'enregistrement, l'enregistrement se termine et un événement connection.disconnect.hangup est suscité. Toutefois, le son enregistré jusqu'au raccrochage reste disponible dans la variable de l'élément record. Les applications, tels les services simples de courrier éléctronique vocal, peuvent ainsi renvoyer des données sonores à un serveur, même après déconnexion :

<?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>
   <record  name="msg" beep="true" maxtime="10s"
       finalsilence="4000ms" dtmfterm="true" type="audio/x-wav">
       <prompt timeout="5s">
         Laissez un message après le bip.
       </prompt>
       <noinput>
         Je n'ai rien entendu, veuillez recommencer.
       </noinput>
       <catch event="connection.disconnect.hangup">
           <submit next="./serveur_courrielvocal.asp"/>
       </catch>
   </record>
</form>
</vxml>

Un enregistrement commence immédiatement après la lecture d'une invite (y compris le bip, le cas échéant). Pour des raisons d'optimisation, une plateforme peut lancer l'enregistrement dès que l'utilisateur commence à parler.

Un délai de temporisation commence immédiatement après la lecture d'une invite (y compris le bip, le cas échéant) et sa durée est déterminée par la propriété timeout. Si le délai de temporisation expire avant le commencement de l'enregistrement, alors un événement noinput est suscité.

Une durée maximale commence en même temps que l'enregistrement et elle est déterminée par un attribut maxtime. Si la durée maximale expire avant que l'enregistrement ne soit fini, alors l'enregistrement est interrompu et la variable fictive de l'attribut maxtime reçoit la valeur "true".

Un enregistrement se termine lorsque un événement est suscité, une entrée vocale ou DTMF est filtrée par une grammaire active ou la durée maximale est dépassée. Pour des raisons d'optimisation, une plateforme peut interrompre un enregistrement après un délai de silence (fixé par l'attribut finalsilence) indiquant que l'utilisateur a cessé de parler.

Si aucun son n'est recueilli pendant l'exécution de l'élément record, alors la variable d'enregistrement reste vide (voir remarque). Cela peut se produire, par exemple, lorsqu'une entrée vocale ou DTMF est reçue pendant la lecture de l'invite ou avant que l'intervalle de temporisation n'expire. En particulier, si aucun son n'est recueilli avant que l'utilisateur ne termine l'enregistrement par une entrée DTMF correspondant à une grammaire DTMF locale (ou quand la valeur de l'attribut dtmfterm est fixée à "true"), alors la variable d'enregistrement n'est pas remplie (et donc aucune variable fictive n'est fixée) et l'algorithme FIA poursuit normalement sans qu'un événement noinput ne soit suscité. Néanmoins, dans ces situations, on peut accéder aux informations concernant l'entrée via le tableau application.lastresult$, comme décrit dans le chapitre 5.1.5.

L'élément record contient un attribut dtmfterm pour des raisons de commodité envers les développeurs. Un attribut dtmfterm avec la valeur "true" équivaut à la définition d'une grammaire DTMF locale filtrant toute entrée DTMF. L'attribut dtmfterm est prioritaire sur les grammaires DTMF locales définies.

N'importe quelle touche DTMF correspondant à une grammaire active termine l'enregistrement. Les touches DTMF qui ne correspondent pas à une grammaire active sont ignorées (et, de fait, ne terminent ni n'affectent d'une quelconque manière l'enregistrement) et la plateforme peut, en option, les supprimer du signal.

La reconnaissance des grammaires vocales par la plateforme pendant l'enregistrement est optionnelle. Si la plateforme gère simultanément la reconnaissance et l'enregistrement, alors une commande vocale filtrée par une grammaire vocale non locale peut terminer l'enregistrement et l'algorithme FIA est invoqué, lequel transfère l'exécution à l'élément contenant la grammaire. La commande vocale terminante est acessible via le tableau application.lastresult$. Par contre, le son de la commande vocale terminante reconnue n'est pas disponible et il ne fait pas partie de l'enregistrement. Remarquez que, au contraire d'une tonalité DTMF, on ne peut pas utiliser une entrée de reconnaissance vocale juste pour terminer l'enregistrement : si des grammaires vocales locales sont définies, elles sont considérées inactives (c'est-à-dire, qu'elles sont ignorées), même si la plateforme gère la reconnaissance et l'enregistrement simultanés.

Si la grammaire de terminaison retenue est une grammaire locale, alors l'enregistrement est placé dans la variable d'enregistrement. Sinon, celle-ci est laissée intacte (voir la remarque) et l'algorithme FIA est invoqué. Quel que soit le cas, le tableau application.lastresult$ sera peuplé.

Remarque : Bien que la variable d'enregistrement ne soit pas remplie dans ce cas, la correspondance d'une grammaire non locale peut néanmoins entraîner l'assignation d'une certaine valeur à la variable d'enregistrement (voir le chapitre 3.1.6).

Les attributs de l'élément record sont :

L'élément record contient les variables fictives suivantes après que l'enregistrement a été réalisé :

2.3.7. L'élément transfer

L'élément transfer instruit l'interpréteur de connecter l'appelant à une autre entité (par exemple, une ligne téléphonique ou une autre application vocale. Pendant l'opération de transfert, la session d'interprétation courante est suspendue.

Une plateforme d'implémentation peut initier un transfert de diverses manières, dont ceux de type pont, aveugle, redirection de réseau (appelé parfois rappel et transfert, transfert par support commutateur, etc. Les transferts de types pont et aveugle sont pris en charge ; les autres types dépendent étroitement des fonctionnalités et des configurations spécifiques des plateformes et des réseaux, c'est la raison pour laquelle ils ne sont pas traités par cette spécification.

L'élément transfer est optionnel, bien que les plateformes devraient le prendre en charge. Les plateformes gérant l'élément transfer devraient gérer les transferts de type pont ou ceux de type aveugle, ou les deux. Celles qui gèrent l'un ou l'autre type de transfert peuvent gérer, en option, les modes d'entrée asynchrones des commandes DTMF, ou des commandes vocale, ou les deux, pendant le transfert d'appel afin d'annuler la tentative de liaison distante. Les tentatives de transfert de type aveugle peuvent s'annuler tant que l'appel sortant n'a pas encore commencé.

Les attributs de l'élément transfer sont :

On ne peut définir qu'un seul exactement entre les attributs dest ou destexpr, sinon, un événement error.badfetch est suscité. De même, on ne peut définir qu'un seul exactement entre les attributs aai ou aaiexpr, sinon, un événement error.badfetch est suscité.

2.3.7.1 Le transfert de type aveugle

Pour un transfert de type aveugle, il se produit une tentative de connecter l'appelant original à l'appelé. Toutes les invites précédant l'élément transfer, ainsi que celles qui y sont contenues, sont mises en file d'attente et jouées avant que la tentative de transfert ne commence ; les propriétés d'interruption s'appliquent normalement.

Figure 8 : Les connexions sonores pendant un transfert de type aveugle : <transfer bridge="false">

Toute source sonore désignée par l'attribut transferaudio est ignorée, car aucun son ne peut être joué depuis la plateforme vers l'appelant au cours de la tentative de transfert. Que la connexion réussisse ou non, la plateforme d'implémentation ne peut pas reprendre le contrôle des connexions.

L'état de la connexion n'est pas disponible. Par exemple, il n'est pas possible de savoir si l'appelé était occupé, quand un appel réussi se termine, etc. Toutefois, certaines conditions d'erreur peuvent être signalées lorsque la plateforme en a connaissance, comme quand l'appelant n'est pas autorisé à appeler la destination ou quand l'adresse URI de la destination est malformée. Ces conditions sont propres à la plateforme mais elles devraient obéir aux conventions de nommage des valeurs de transfert des autres variables d'élément de formulaire.

L'appelant peut annuler la tentative de transfert avant que l'appel sortant ne commence, en l'interrompant par une commande vocale ou DTMF qui corresponde à une grammaire active, au cours de la lecture de n'importe quel son mis en file d'attente.

Auquel cas, la variable d'élément de formulaire est fixée tout comme les variables fictives suivantes :

Le tableau application.lastresult$ sera également rempli comme décrit dans le chapitre 5.1.5.

Si l'appelant se déconnecte en raccrochant au cours de la tentative de transfert d'appel, avant que la connexion à l'appelé n'ait commencé, alors un événement connection.disconnect.hangup sera suscité et l'exécution du dialogue passera au gestionnaire de l'événement hangup (le cas échéant). La variable d'élément de formulaire et, par conséquent, les variables fictives ne seront pas fixées.

Une fois le transfert lancé et l'interpréteur déconnecté de la session, la plateforme suscite un événement connection.disconnect.transfer et l'interprétation du document se poursuit normalement.

Toute connexion entre l'appelant et l'appelé reste en place indépendamment de l'exécution du document.

2.3.7.2 Le transfert de type pont

Pour un transfert de type pont, la plateforme connecte l'appelant à l'appelé dans une conversation bidirectionnelle simultanée.

Figure 9 : Les connexions sonores au cours d'un transfert de type pont : <transfer bridge="true">

Toutes les invites précédant l'élément transfer, ainsi que celles qui y sont contenues, sont mises en file d'attente et jouées avant que la tentative de transfert ne commence ; les propriétés d'interruption s'appliquent normalement. La définition de l'attribut bargeintype est ignorée ; sa valeur implicite est "hotword".

L'appelant peut annuler la tentative de transfert avant que l'appel sortant ne commence, en l'interrompant par une commande vocale ou DTMF qui corresponde à une grammaire active, au cours de la lecture de n'importe quel son mis en file d'attente.

2.3.7.2.1 L'écoute d'une entrée d'utilisateur au cours d'un transfert

Les platformes peuvent, en option, gérer une écoute des commandes de l'appelant pour terminer le transfert en définissant une ou plusieurs grammaires dans l'élément transfer. L'élément transfer est modal, c'est-à-dire que les grammaires définies hors de sa portée sont inactives. Pendant la lecture des invites et pendant la totalité des phases de connexion et de discours du transfert, la plateforme surveillera :

• les entrées DTMF de l'appelant correspondant à une grammaire DTMF incluse ;
• les énoncés de l'appelant correspondant à une grammaire vocale incluse

Un filtrage réussi terminera le transfert (la connexion à l'appelé) ; l'interprétation du document se poursuit normalement. Un filtrage non réussi sera ignoré. Si aucune grammaire n'est définie, alors la plateforme n'écoutera pas les entrées de l'appelant.

La plateforme ne surveille pas les signaux intrabandes ou les commandes vocales de l'appelé.

2.3.7.2.2 La gestion des déconnexions de l'appelant, de l'appelé ou du réseau

Tout en essayant de se connecter à l'appelé, la plateforme surveille les indicateurs de progression de l'appel (intrabandes ou hors bande, selon le type de connexion et les protocoles particuliers). Pour la durée d'un transfert réussi, la plateforme surveille les événements téléphoniques (hors bande), telle qu'une déconnexion, aux deux extrêmités de la liaison.

Si l'appelé se déconnecte, alors l'appelant reprend sa session avec l'interpréteur. Si c'est l'appelant, alors la plateforme déconnecte l'appelé et l'interprétation du document se poursuit normalement. Si l'appelant et l'appelé sont tous deux déconnectés par le réseau, alors l'interprétation du document se poursuit normalement.

Les résultats possibles pour un transfert de type pont, avant que la connexion à l'appelé ne soit établie, sont :

Les résultats possibles pour un transfert de type pont, après que la connexion à l'appelé est établie, sont :

Si l'appelant se déconnecte en raccrochant (soit lors du transfert d'appel, soit lors de la tentative de transfert d'appel), alors la connexion à l'appelé (le cas échéant) est abandonnée, un événement connection.disconnect.hangup est suscité et l'exécution du dialogue va passer au gestionnaire de l'événement hangup (le cas échéant). La variable d'élément de formulaire et, par conséquent, les variables fictives ne seront pas fixées.

Si l'exécution de l'élément transfer se poursuit normalement, alors sa variable d'élément de formulaire est fixée, tout comme les variables fictives suivantes :

Si le transfert a été terminé par une commande vocale, alors le tableau application.lastresult$ est rempli normalement.

2.3.7.2.3 Le son au cours d'une tentative de transfert de type pont

Au cours d'un transfert de type pont, on peut vouloir jouer un son à l'appelant pendant que la plateforme essaye de se connecter à l'appelé. Par exemple, une publicité (Achetez la mayonnaise de tante Louise !) ou bien un message d'information (Votre avis nous intéresse ; veuillez patienter pendant que nous vous connectons au premier agent disponible.) seraient susceptibles de remplacer les indications de progression de l'appel (sonnerie, tonalité occupé, état du réseau, etc.).

À l'instant où commence l'appel sortant, le son défini par l'attribut transferaudio est joué. La lecture du son s'achève lorsque l'état de la réponse de la connexion distante est déterminé. Cet état n'est pas toujours connu, car le commutateur distant peut jouer un son (tels qu'une tonalité d'information particulière, une tonalité occupé, une tonalité de réseau encombré ou un enregistrement annonçant l'impossibilité d'établir la connexion) sans répondre réellement à l'appel.

Si la durée du fichier son spécifié est inférieure au temps nécessaire à la connexion distante, alors l'appelant pourra entendre un silence, un son propre à la plateforme ou une indication de progression de l'appel, selon la plateforme.

2.3.7.3 Les erreurs et événement au cours du transfert

Au cours d'un transfert, l'un des événements suivants pourra être suscité :

Si une tentative de transfert a échoué, l'une des erreurs suivantes sera suscitée :

2.3.7.4 Exemple

L'exemple suivant montre la tentative de transfert de type pont d'un appelant à un tiers puis l'attente de la fin de la conversation. On peut inclure des invites avant ou dans l'élément transfer : elles peuvent servir à informer l'appelant de ce qui se déroule, avec un avis tel que Veuillez patienter, nous transférons votre appel. L'invite de l'élément block et celle de l'élément transfer sont mises en file d'attente puis jouées avant le transfert effectif. Après purge de la file d'attente des sons, l'appel sortant est initié. Par défaut, l'appelant est connecté à la voie téléphonique sortante. L'attribut transferaudio définit le fichier son à jouer à l'appelant, au lieu du fichier son distant, jusqu'à ce que l'hôte distant réponde. Si la durée de la source sonore est plus longue que celle du temps pour établir la connexion, alors la lecture du son cessera immédiatement dès la réponse distante.

Figure 10 : Le diagramme des séquences et des temporisations dans un exemple de transfert de type pont

<?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="xfer">
   <var name="ma_duree" expr="0"/>
   <block>
     <!-- Mis en file d'attente et joué avant le début du transfert -->
     <prompt>
        Appel de Riley en cours. Veuillez patienter.
     </prompt>
   </block>

   <!-- Joue une musique pendant la tentative de connexion à l'hôte distant -->
   <!-- L'attribut bargeintype a la valeur "hotword" seulement
           pendant la durée de l'attribut transferaudio -->
   <!-- Attend jusqu'à 60 secondes la réponse distante -->
   <transfer name="mon_appel" dest="tel:+33-1234567890"
      transferaudio="musique.wav" connecttimeout="60s" bridge="true">

     <!-- Mis en attente et joué avant le début du transfert -->
     <!-- Les propriétés d'interruption s'applique pour cette invite -->
     <prompt>
        Dites annuler pour vous déconnecter à tout instant.
     </prompt>

     <!-- Définit une grammaire externe à écouter pour la commande annuler -->
     <grammar src="annuler.grxml" type="application/srgs+xml"/>

     <filled>
       <assign name="ma_duree" expr="mon_appel$.duration"/>
         <if cond="mon_appel == 'busy'">
           <prompt>
             La ligne de Riley est occupée. Veuillez rappeller plus tard.
           </prompt>
         <elseif cond="mon_appel == 'noanswer'"/>
           <prompt>
             Riley ne répond pas. Veuillez rappeler plus tard.
           </prompt>
         </if>
     </filled>
   </transfer>

   <!-- Envoie les statistiques d'appel au serveur -->
   <block>
      <submit namelist="mon_appel ma_duree" next="/cgi-bin/rapport"/>
   </block>
</form>
</vxml>

2.4 L'élément filled

L'élément filled indique l'action à effectuer lorsqu'une certaine combinaison d'éléments d'entrée est remplie. Il peut apparaître dans deux endroits : comme enfant de l'élément form ou comme enfant d'un élément d'entrée.

Comme enfant d'un élément form, l'élément filled peut servir à accomplir des actions survenant lorsqu'une combinaison d'un ou plusieurs éléments d'entrée est remplie. Par exemple, l'élément filled suivant effectue une vérification croisée afin de s'assurer que le champ de la ville de départ diffère du champ de la ville d'arrivée :

<?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_villes_depart_et_arrivee">
  <field name="ville_depart">
      <grammar src="http://www.grammars.example.com/voicexml/ville.grxml" 
        type="application/srgs+xml"/>
      <prompt>Quelle est la ville de départ ?</prompt>
  </field>
  <field name="ville_arrivee">
      <grammar src="http://www.grammars.example.com/voicexml/ville.grxml" 
        type="application/srgs+xml"/>
      <prompt>Quelle est la ville d'arrivée ?</prompt>
  </field>
  <filled mode="all" namelist="ville_depart ville_arrivee">
    <if cond="ville_depart == ville_arrivee">
      <prompt>
        Vous ne pouvez partir d'une ville et y arriver.
      </prompt>
      <clear/>
    </if>
  </filled>
</form>
</vxml>

Si l'élément filled apparaît dans un élément d'entrée, alors il indique l'action à effectuer après que l'élément d'entrée a été rempli 

<?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_ville">
  <field name="ville">
    <grammar type="application/srgs+xml"
      src="http://www.livraison.example.com/grammars/villes_desservies.grxml"/>
    <prompt>Quelle est la ville ?</prompt>
    <filled>
      <if cond="ville == 'Novosibirsk'">
        <prompt>
          Notez que Novosibirsk ne sera plus désservie l'année prochaine.
        </prompt>
      </if>
    </filled>
  </field>
</form>
</vxml>

Après chaque recueil d'une entrée d'utilisateur, tous les éléments d'entrée mentionnés dans l'entrée sont fixés et l'interpréteur examine alors chaque élément filled, dans l'ordre du document (sans préférence donnée à ceux dans les éléments d'entrée vis-à-vis de ceux dans le formulaire). Les éléments filled dont les conditions vérifient l'énoncé sont alors exécutés dans l'ordre, jusqu'à ce qu'il n'y en ait plus, ou jusqu'à ce que l'un transfère le contrôle ou suscite un événement.

Les attributs de l'élément filled comprennent :

2.5 Les liens

Un élément link peut avoir une ou plusieurs grammaire dont la portée s'exerce sur l'élément le contenant. Un attribut scope sur l'élément contenant l'élément link n'exerce aucun effet sur la portée des grammaires de l'élément link (par exemple, lorsqu'un élément link est contenu dans un élément form déclarant scope="document", les grammaires de l'élément link s'exercent sur le formulaire, et non sur le document). Les éléments grammar contenus dans l'élément link ne peuvent pas définir d'attribut scope (voir le chapitre 3.1.3 pour des précisions). Lorsque l'une de ces grammaires correspond, le lien s'active et effectue :

• Soit une transition vers un nouveau document ou dialogue (comme l'élément goto) ;

• Soit suscite un événement (comme l'élément throw).

Par exemple, le lien suivant s'active quand on dit livres ou qu'on tape 2.

<link next="http://www.voicexml.org/livres/principal.vxml">
  <grammar mode="voice" version="1.0" root="racine">
    <rule id="racine" scope="public">
       <one-of>
         <item>livres</item> 
         <item>livres VoiceXML</item> 
       </one-of>
    </rule>
  </grammar>
  <grammar mode="dtmf" version="1.0" root="r2">
     <rule id="r2" scope="public"> 2 </rule>
  </grammar>
</link>

Ce lien mène à un dialogue déterminé dynamiquement dans le document courant :

<link expr="'#' + document.helpstate">
  <grammar mode="voice" version="1.0" root="racine">
     <rule id="racine" scope="public"> help </rule>
  </grammar>
</link>

L'élément link peut être enfant des éléments vxml, ou form, ou des éléments de formulaire field et initial. Les grammaires d'un élément link au niveau de l'élément vxml sont actives pour tout le document. Les grammaires d'un élément link au niveau d'un élément form sont actives tant que l'utilisateur reste dans le formulaire. Si un document racine d'application contient un lien de niveau document, alors les grammaires du lien sont actives, quel que soit le document de l'application exécuté.

Si l'exécution se produit dans un élément de formulaire modal, alors les grammaires du lien, que ce soit au niveau formulaire, document ou bien application, ne sont pas actives.

On peut aussi définir un lien qui, dès lors qu'il est activé, suscite un événement au lieu de mener à un nouveau document. L'événement est suscité à l'emplacement courant de l'exécution, et non à l'emplacement où le lien est défini. Dans l'exemple suivant, si l'utilisateur sollicite la grammaire du lien ou tape 2 au clavier, un événement help est suscité dans l'élément de formulaire que visitait l'utilisateur et celui-ci est géré par l'élément catch le mieux qualifié dans la portée de l'élément (voir le chapitre 5.2.4 pour des précisions) :

<link dtmf="2" event="help">
  <grammar mode="voice" version="1.0" root="r5">
    <rule id="r5" scope="public">
       <one-of>
         <item>arrgh</item> 
         <item>hélas tout est perdu !</item> 
         <item>allez ! machine de m.....</item> 
         <item>Je n'y comprends rien</item> 
       </one-of>
    </rule>
  </grammar>
</link>

Lorsque le lien est activé, le tableau application.lastresult$ se remplit. Cela permet de prendre des décisions en réception dans le flux des appels en fonction du résultat sémantique réel. Voir un exemple dans le chapitre 5.1.5.

Les attributs de l'élément link sont :

On ne peut définir qu'un seul exactement entre les attributs next, expr, event ou eventexpr, sinon, un événement error.badfetch est suscité. De même, on ne peut définir qu'un seul exactement entre les attributs message ou messageexpr, sinon, un événement error.badfetch est suscité.

3. L'entrée d'utilisateur

3.1 Les grammaires

3.1.1 Les grammaires vocales

L'élément grammar peut servir à introduire une grammaire vocale, laquelle :

• définit un ensemble d'énoncés susceptibles d'être prononcés par un utilisateur pour effectuer une action ou fournir une information, et

• lorsque l'énoncé est avéré, renvoie une interprétation sémantique correspondante. Il peut s'agir d'une valeur simple (comme une chaîne), d'un ensemble non hiérarchique de couples attribut-valeur (tel qu'un jour, un mois et une année) ou d'un objet imbriqué (pour une requête complexe).

L'élément grammar est conçu de manière à s'accommoder de n'importe quel format de grammaire qui satisfait à ces deux conditions. Les plateformes VoiceXML doivent reconnaître au moins un format courant, à savoir la forme XML décrite dans la spécification des grammaires de reconnaissance vocale du W3C [SRGS]. Elles devraient reconnaître la forme ABNF décrite dans cette même spécification [SRGS]. Les plateformes VoiceXML peuvent choisir de gérer d'autres formats que ceux de la spécification SGRS. Par exemple, une plateforme pourrait se servir de la gestion du type PCDATA offerte par l'élément grammar pour introduire directement une définition de grammaire propriétaire ou mettre à profit les attributs src et type pour en introduire une externe.

Les plateformes VoiceXML doivent correspondre à la définition d'un processeur de grammaire de forme XML conforme donnée dans la spécification des grammaires de reconnaissance vocale du W3C [SRGS]. Bien que cette définition exige d'une plateforme qu'elle puisse traiter des documents ayant un ou plusieurs attributs xml:lang, elle n'exige pas qu'elle soit multilingue. Lorsqu'elle rencontre une langue non reconnue, la plateforme suscite un événement error.unsupported.language indiquant quelle langue n'est pas reconnue dans sa variable message.

Les éléments des grammaires SGRS de forme XML

Les éléments suivants sont définis pour les grammaires de forme XML dans la spécification des grammaires de reconnaissance vocale du W3C [SRGS] et sont disponibles dans le langage VoiceXML 2.0. Le présent document ne redéfinit pas ces éléments. Veuillez consulter la spécification des grammaires de reconnaissance vocale du W3C [SRGS] pour les définitions et des exemples.

3.1.1.1 Les grammaires directes

On peut utiliser l'élément grammar pour définir une grammaire directe ou bien externe. Une grammaire directe se compose du contenu d'un élément grammar et c'est une grammaire complète :

<grammar type="type-média" mode="voice">
     grammaire vocale directe
</grammar>

Il est parfois nécessaire, dans ce cas, d'englober le contenu dans une section de type CDATA [XML]. Pour les grammaires directes, l'attribut type précise le type de média régissant l'interprétation du contenu de l'élément grammar.

Voici un exemple de grammaire directe de forme XML inspiré de la spécification des grammaires de reconnaissance vocale du W3C [SRGS] :

<grammar mode="voice" xml:lang="fr" version="1.0" root="commande">
  <!-- La commande consiste en une action sur un objet -->
  <!-- par exemple, "ouvrir une fenêtre" -->
  <rule id="commande" scope="public">
    <ruleref uri="#action"/> <ruleref uri="#objet"/>
  </rule>

  <rule id="action">
    <one-of>
      <item> ouvrir </item>
      <item> fermer </item>
      <item> effacer </item>
      <item> déplacer </item>
    </one-of>
  </rule>

  <rule id="objet">
    <item repeat="0-1">
      <one-of>
        <item> le </item>
        <item> la </item>
        <item> un </item>
        <item> une </item>
      </one-of>
    </item>
    <one-of>
      <item> fenêtre </item>
      <item> fichier </item>
      <item> menu </item>
    </one-of>
  </rule>
</grammar>

Voici un exemple de grammaire directe équivalent cette fois dans la forme ABNF de la spécification [SRGS]. Les plateformes VoiceXML n'étant pas obligées de gérer ce format, sa portabilité est peut-être moindre :

<grammar mode="voice" type="application/srgs">
#ABNF 1.0;
language fr;
mode voice;
root $commande;
  public $commande = $action $objet;
  $action = ouvrir | fermer | effacer | déplacer;
  $objet = [le | la | un | une] (fenêtre | fichier | menu);
</grammar>

3.1.1.2 Les grammaires externes

On définit une grammaire externe de la manière suivante :

<grammar src="adresse-URI" type="type-média"/>

Dans ce cas, le type de média est optionnel parce que le contexte d'interprétation essaiera de le déterminer dynamiquement comme décrit dans le chapitre 3.1.1.4.

Si l'attribut src est défini et qu'une grammaire directe se trouve en contenu d'un élément grammar, alors un événement error.badfetch est suscité.

Voici l'exemple de l'appel d'une grammaire externe créée dans la forme XML de la spécification des grammaires de reconnaissance vocale du W3C [SRGS] :

<grammar type="application/srgs+xml" src="http://www.grammaire.example.com/date.grxml"/>

L'exemple suivant illustre l'appel d'une grammaire externe créée dans la forme ABNF de la spécification [SRGS] :

<grammar type="application/srgs" src="http://www.grammaire.example.com/date.gram"/>

3.1.1.3 Le poids des grammaires

On peut définir le poids d'une grammaire au moyen de l'attribut weight :

<grammar weight="0.6" src="formulaire.grxml" type="application/srgs+xml"/>

Les éléments grammar, y compris ceux dans les éléments link, field et form, peuvent recevoir un attribut weight, que la grammaire soit directe, externe ou bien intégrée.

L'application des poids obéit à la définition du poids des alternatives dans la spécification [SRGS §2.4.1]. Un poids est une valeur en virgule flottante positive simple sans exponentielle. Les valeurs légales prennent les formes "n", "n.", ".n" et "n.n", où n représente une séquence composée d'un ou plusieurs chiffres.

Symboliquement, un poids est un facteur de multiplication dans la sphère de recherche d'une reconnaissance vocale. Un poids de "1.0" équivaut à ne pas fournir de poids du tout. Un poids supérieur à "1.0" fait valoir la grammaire de manière positive et, inversement, un poids inférieur à "1.0" fait valoir la grammaire de manière négative. Si on ne définit pas de poids, alors le poids implicite d'une grammaire vaut "1.0". Si aucun élément grammar n'a d'attribut weight, alors toutes les grammaires ont un poids équivalent.

<link event="help">
  <grammar weight="0.5" mode="voice" version="1.0" root="aide">
   <rule id="aide" scope="public">
      aide <item repeat="0-1"> s'il vous plaît </item>
   </rule>  
  </grammar>
</link>

<form>
  <grammar src="formulaire.grxml" type="application/srgs+xml"/>
  <field name="date_expiration">
     <grammar weight="1.2" src="http://www.example.org/grammaire/date"/>
  </field>
</form>

Dans l'exemple précédent, la sémantique des poids équivaut à la grammaire XML suivante :

<grammar root="r1" type="application/srgs+xml">
<rule id="r1">
  <one-of>
    <item weight="0.5"> <ruleref uri="#aide"/> </item>
    <item weight="1.0"> <ruleref uri="formulaire.grxml"/> </item>
    <item weight="1.2"> <ruleref uri="http://www.example.org/grammaire/date"/></item>
  </one-of>
</rule>

<rule id="aide">
  aide <item repeat="0-1"> s'il vous plaît </item>
</rule>
</grammar>

Les grammaires implicites, comme celles des éléments option, ne gèrent pas les poids : utilisez plutôt l'élément grammar afin de contrôler le poids des grammaires.

Les poids des grammaires n'affectent que leur traitement. Ils n'influent pas directement sur le post-traitement des résultats des grammaires, y compris la préséance des grammaires lorsque l'entrée d'utilisateur correspond à plusieurs grammaires actives (voir le chapitre 3.1.4).

Les poids n'ont pas d'influence sur les grammaires DTMF (voir le chapitre 3.1.2). Tout attribut weight défini dans un élément grammar dont l'attribut mode vaut "dtmf" sera ignoré.

<!-- le poids sera ignoré -->
<grammar mode="dtmf" weight="0.3" src="http://www.example.org/dtmf/number"/> 

Il est difficile de déterminer les poids appropriés et l'estimation des poids n'améliore pas toujours les performances de la reconnaissance. Les poids effectifs s'obtiennent généralement en étudiant les données vocales et textuelles réelles sur une plateforme particulière. En outre, le poids d'une grammaire est propre à la plateforme. Remarquez que des moteurs de reconnaissance vocale automatique peuvent traiter le même poids différemment. C'est pourquoi, la valeur de poids qui fonctionne bien sur une plateforme particulière peut donner des résultats différents sur d'autres plateformes.

3.1.1.4 L'élément grammar

Les attributs de l'élément grammar, hérités de la spécification des grammaires de reconnaissance vocale du W3C [SRGS] sont :

L'utilisation et l'interprétation de ces attributs se déterminent comme suit :

1. Pour la forme XML directe SRGS : déterminées par la spécification des grammaires de reconnaissance vocale du W3C, laquelle déclare que l'attribut version est obligatoire et doit avoir la valeur "1.0", que l'attribut root est obligatoire et sa valeur identifie la règle à activer et que d'autres attributs sont optionnels (voir la spécification [SRGS] pour des précisions).
2. Pour la forme ABNF directe SRGS : tous les attributs définis doivent être ignorés par la plateforme.
3. Pour les formes XML et ABNF externes SRGS : tous les attributs définis doivent être ignorés par la plateforme.
4. Pour tous les autres types de grammaire : l'utilisation et l'interprétation des attributs définis dépendent de la plateforme.

Les attributs de l'élément grammar rajoutés par VoiceXML 2.0 sont :

On doit définir soit un attribut src, soit une grammaire directe (mais pas les deux en même temps), sinon un événement error.badfetch sera suscité.

Le langage VoiceXML 2.0 renforce également l'élément grammar afin de permettre les données de type PCDATA dans les formats des grammaires directes, parallèlement à la forme XML de la spécification des grammaires de reconnaissance vocale du W3C [SRGS].

Lors de l'appel d'une grammaire externe, la valeur de l'attribut src est une adresse URI, indiquant l'emplacement de la grammaire, qui comporte un éventuel fragment identifiant le nom d'une règle. Le chapitre 2.2 de la spécification des grammaires de reconnaissance vocale [SRGS] définit plusieurs formes d'appel de règle. Voici celles permises sur l'élément grammar dans VoiceXML :

• Appel d'une règle nommée dans une grammaire externe : L'attribut src est un appel d'adresse URI absolue ou relative d'une grammaire, laquelle adresse comprend un fragment identifiant le nom d'une règle. Cette forme d'appel de règle dans une grammaire externe obéit au comportement défini dans le chapitre 2.2.2 de la spécification [SRGS]. Si l'adresse URI mène à rien ou si le nom de la règle n'est pas défini dans la grammaire ou si ce n'est pas une règle publique (activable) de cette grammaire, alors un événement error.badfetch est suscité.
• Appel de la règle racine d'une grammaire externe : L'attribut src est un appel d'adresse URI absolue ou relative d'une grammaire mais qui ne comprend pas de fragment identifiant un nom de règle. Cette forme appelle implicitement la règle racine de la grammaire, comme défini dans le chapitre 2.2.2 de la spécification [SRGS]. Si l'adresse URI mène à rien ou si on ne peut pas appeler la grammaire par sa racine (voir le chapitre 4.7 de la spécification [SRGS]), alors un événement error.badfetch est suscité.

Voici les formes d'appel de règle définies par la spécification [SRGS] mais non gérées dans VoiceXML 2.0 :

• Appel de règle local : Une adresse URI composée seulement d'un fragment n'est pas permise. (Voir une définition dans le chapitre 2.2.1 de la spécification [SRGS]). Une valeur de ce type pour l'attribut src suscitera un événement error.semantic.
• Appel des règles spéciales : Bien qu'une grammaire directe puisse appeler les règles spéciales SRGS (NULL, VOID et GARBAGE, il n'existe aucune prise en charge des appels de règle spéciale sur l'élément grammar même. (Voir les définitions dans le chapitre 2.2.3 de la spécification [SRGS]). Cette forme n'offre aucune gestion syntaxique et elle ne peut donc pas générer d'erreur.

3.1.2 Les grammaires DTMF

L'élément grammar peut servir à introduire une grammaire DTMF, laquelle :

• définit un ensemble de touches susceptibles d'être appuyées par un utilisateur pour effectuer une action ou fournir une information, et

• lorsque l'entrée DTMF est avérée, renvoie une interprétation sémantique correspondante. Il peut s'agir d'une valeur simple (comme une chaîne), d'un ensemble non hiérarchique de couples attribut-valeur (tel qu'un jour, un mois et une année) ou d'un objet imbriqué (pour une requête complexe).

Les plateformes VoiceXML doivent obligatoirement gérer le format XML des grammaires DTMF, défini dans l'annexe D de la spécification [SRGS], pour prétendre à la portabilité des applications.

Une grammaire DTMF se distingue d'une grammaire vocale au moyen de l'attribut mode sur l'élément grammar. L'attribut xml:lang n'a aucune influence sur la gestion des grammaires DTMF. Ces différences mises à part, les grammaires vocales et DTMF se manipulent de manière identique, dont la possibilité de définir une grammaire directe ou d'appeler une grammaire externe. La gestion des types de média, les règles de portée et les règles de recherche sont également les mêmes.

Voici un exemple de grammaire DTMF directe de forme XML qui accepte en entrée "1 2 3" ou "#" :

<grammar mode="dtmf" version="1.0" root="root">
  <rule id="root" scope="public">
    <one-of>
      <item> 1 2 3 </item>
      <item> # </item>
    </one-of>
  </rule>
</grammar>

3.1.3 La portée des grammaires

Les grammaires des éléments d'entrée recouvrent toujours l'élément d'entrée contenant, c'est-à-dire qu'elles sont actives seulement quand l'élément d'entrée contenant a été choisi au cours de la phase de sélection de l'algorithme FIA. Les grammaires contenues dans les éléments d'entrée ne peuvent pas définir de portée, auquel cas un événement error.badfetch est suscité.

Les grammaires des liens reçoivent la portée de l'élément contenant le lien. Ainsi, quand elles sont définies dans le document racine d'application, les liens sont également actifs dans n'importe quel document chargé appartenant à l'application. Les grammaires contenues dans les liens ne peuvent pas définir de portée, auquel cas un événement error.badfetch est suscité.

Les grammaires des formulaires reçoivent implicitement une portée de dialogue, de sorte qu'elles sont actives seulement quand l'utilisateur est dans le formulaire. Si elles reçoivent une portée de document, alors elles sont actives dès que l'utilisateur est dans le document. Si elles reçoivent une portée de document et que le document est celui racine d'application, alors elles sont également actives dès lors que l'utilisateur est dans un autre document chargé appartenant à la même application. On peut donner une portée de document à une grammaire de formulaire soit en définissant l'attribut scope sur l'élément form, soit en le définissant sur l'élément grammar. Si les deux sont définis, alors la grammaire tiendra compte de la portée définie sur l'élément grammar.

Les grammaires des menus reçoivent également une portée de dialogue implicite et elles sont actives seulement quand l'utilisateur est dans le menu. Cependant, elles peuvent recevoir une portée de document et être active dans tout le document, et, si celui-ci est le document racine d'application, dans tout document chargé appartenant à l'application. Les grammaires contenues dans les choix de menu ne peuvent pas définir de portée, auquel cas un événement error.badfetch est suscité.

Parfois, un formulaire peut avoir besoin que certaines grammaires soient actives dans tout le document et que d'autres ne le soient que dans le formulaire. Ceci afin de minimiser les problèmes de recoupement. Pour ce faire, on peut donner à chaque élément grammar individuel une portée propre dans la mesure où cette portée doit être différent de celle de l'élément form :

<?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 scope="document"> 
  <grammar type="application/srgs"> 
    #ABNF 1.0;
    language fr;
    mode voice;
    root $commande;
    public $commande = un | deux | trois;
  </grammar> 
  <grammar type="application/srgs" scope="dialog"> 
    #ABNF 1.0;
    language fr;
    mode voice;
    root $commande2;
    public $commande2 = quatre | cinq | six;
  </grammar> 
</form>
</vxml>

3.1.4 L'activation des grammaires

Lorsque l'interpréteur attend une entrée en résultat de la visite d'un élément d'entrée, voici les grammaires qui sont actives :

1. les grammaires de cet élément d'entrée, y compris celles contenues dans les liens de cet élément d'entrée ;

2. les grammaires de son formulaire, y compris celles contenues dans les liens de ce formulaire ;

3. les grammaires contenues dans les liens de son document, et les grammaires des menus et des autres formulaires dans son document ayant reçu une portée de document ;

4. les grammaires contenues dans les liens de son document racine d'application, et les grammaires des menus et des formulaires dans son document racine d'application ayant reçu une portée de document.

5. les grammaires définies par les gestionnaires d'événements implicites de la plateforme, tels que les événements help, exit et cancel.

Dans le cas où une entrée est avérée dans plusieurs grammaires actives, c'est la liste précédente qui définit l'ordre de préséance. Si l'entrée est avérée dans plusieurs grammaires actives avec la même priorité, alors la préséance se détermine dans l'ordre du document : la première grammaire dans l'ordre du document aura la priorité la plus élevée. Si aucune grammaire n'est active dans l'attente d'une entrée, alors la plateforme doit susciter un événement error.semantic. L'erreur sera suscitée dans le contexte de l'élément en cours d'exécution. Les menus se comportent, en ce qui concerne l'activation des grammaires, comme les formulaires équivalents (voir le chapitre 2.2.1).

Si l'élément de formulaire est modal (c'est-à-dire que son attribut mode a la valeur "true"), alors toutes les grammaires, sauf les siennes, sont neutralisées dans l'attente d'une entrée. Si l'entrée est avérée dans la grammaire d'un formulaire (ou d'un menu) autre que le formulaire (ou le menu) courant, alors le contrôle passe à l'autre formulaire (ou menu). Si, en raison d'une correspondance, le contrôle quitte le formulaire courant, alors toutes les données du formulaire courant seront perdues.

L'activation des grammaires n'est pas affectée par la propriété inputmodes. Par exemple, quand la propriété inputmodes impose une entrée vocale, les grammaires DTMF resteront actives mais ne pourront être sollicitées.

3.1.5 L'interprétation sémantique de l'entrée

La spécification des grammaires de reconnaissance vocale définit l'élément tag dont le contenu permet l'interprétation sémantique des grammaires vocales ou DTMF (voir le chapitre 2.6 de la spécification [SRGS]).

La spécification de l'interprétation sémantique de la reconnaissance vocale [SISR] décrit la syntaxe et la sémantique de ces éléments tag, et définit comment calculer l'interprétation sémantique d'une entrée d'utilisateur en utilisant le contenu des éléments tag associés aux atomes et règles qui correspondent. L'interprétation sémantique peut s'appliquer dans VoiceXML, comme décrit dans le chapitre 3.1.6.

3.1.6 L'application des résultats de l'interprétation sémantique au formulaires VoiceXML

L'interprétation sémantique issue d'une grammaire SRGS [SRGS] doit être appliquée à une ou plusieurs variables ECMAScript VoiceXML. Le processus initiateur diffère légèrement entre les résultats de niveau formulaire et ceux de niveau champ ; ces différences seront examinées dans les chapitres suivants. Le format de l'interprétation sémantique, utilisant soit le langage de balisage sémantique en langue naturelle NLSML [NLSML], soit le format de sortie apparenté ECMAScript de la spécification [SISR], ne revêt pas d'importance pour cette discussion. Pour les besoins de l'explication, le résultat réel issu du logiciel de reconnaissance est supposé s'appliquer dans un format apparenté ECMAScript identique à la représentation trouvée dans la variable application.lastresult$.interpretation, abordée dans le chapitre 5.1.5.

Une grammaire peut éventuellement correspondre mais ne pas renvoyer d'interprétation sémantique. Auquel cas, la plateforme utilisera la chaîne de texte brut de l'énonce comme résultat sémantique. Sinon, ce cas est traité exactement comme si l'interprétation sémantique consistait en une valeur simple.

Chaque élément d'entrée a un nom de facette qui peut servir à extraire une partie de l'interprétation sémantique entière. Le nom de facette corresponde à la valeur de l'attribut slot, le cas échéant (seulement possible pour les éléments field), ou, sinon, à la valeur de l'attribut name (pour les éléments field sans attribut slot ainsi que pour les autres éléments d'entrée). Si ni l'attribut slot ni l'attribut name sont présents, alors le nom de facette n'est pas défini.

Le nom de facette sert au cours de la phase de traitement de l'algorithme FIA pour déterminer si un élément d'entrée correspond ou non. Il y a correspondance lorsque le nom de facette est le même que celui d'une propriété de niveau supérieur ou bien lorsqu'un nom de facette sert à sélectionner une sous-propriété. Une propriété dont la valeur n'est pas définie (c'est-à-dire, la valeur ECMAScript "undefined") ne correspondra pas. Tout comme les noms de facette non définis ne correspondront jamais. On trouvera des exemples dans le chapitre 3.1.6.3. Remarquez qu'une valeur d'attribut slot peut remplir plusieurs éléments d'entrée si les noms de facette des éléments d'entrée sont les mêmes.

Les chapitres suivants traitent de l'application des résultats de niveau formulaire et de niveau champ. Il y aura également une brève explication d'autres problèmes tels que l'application de la sémantique en langue naturelle au langage ECMAScript, le passage des informations issues des résultats de la reconnaissance vocale automatique au langage VoiceXML et le traitement des contradictions entre le résultat d'interprétation et le formulaire VoiceXML.

3.1.6.1 L'application des résultats de niveau formulaire

Les grammaires définies à un niveau formulaire produisent un résultat de niveau formulaire pouvant remplir plusieurs éléments d'entrée simultanément. Il peut arriver, à tout instant, que ce soit dans un élément initial ou bien dans un élément d'entrée, qu'une entrée d'utilisateur corresponde à une grammaire de niveau formulaire active.

Prenons le résultat de l'interprétation de la phrase Je voudrais un verre d'eau et trois grandes pizzas au poivron et aux champignons. L'interprétation sémantique peut se copier dans la variable application.lastresult$.interpretation comme :

{
     boisson: "eau",
     pizza: {
          quantite: "3",
          taille: "grande",
           garniture: [
                "poivron",
                "champignon"
           ]
      }
}

Le tableau suivant illustre comment ce résultat issu d'une grammaire de niveau formulaire sera affecté aux divers éléments d'entrée dans le formulaire. Remarquez que tous les éléments d'entrée susceptibles d'être remplis le sont simultanément. Les valeurs existantes des variables d'éléments d'entrée correspondants seront écrasées et ces éléments seront marqués pour le traitement filled au cours de la phase de traitement de l'algorithme FIA, comme décrit dans le chapitre 2.4 et l'annexe C.

On peut expliquer les exemples <field ... slot="pizza.quelquechose"> précédents par des règles qui sont compatibles avec les attributs name et slot (et qui en sont les prolongements directs) de VoiceXML 1.0 :

1. L'attribut slot d'un élément field est une expression ECMAScript (très limitée) qui sélectionne une certaine partie du résultat à affecter au champ. Outre la sélection de la propriété de résultat de niveau supérieur, l'attribut peut sélectionner des propriétés à des niveaux d'imbrication arbitraires, en utilisant une liste de noms d'éléments/propriétés, séparés par des points, comme, par exemple, pizza.quantite et commande.pizza.garniture.
2. Si on se sert de l'attribut slot d'un champ pour sélectionner une sous-propriété du résultat et que la sous-propriété n'existe pas dans le résultat, alors le champ ne correspond pas au résultat (voir le chapitre 3.1.6).

3.1.6.2 L'application d'un résultat de niveau champ

Les grammaires définies dans un élément d'entrée produisent un résultat de niveau champ pouvant seulement remplir l'élément d'entrée particulier qui les contient. Ces grammaires sont seulement actives quand l'algorithme FIA visite cet élément d'entrée particulier. Cela peut se révéler utile, par exemple, pour des dialogues dirigés dans lesquels l'utilisateur fait l'objet d'une invite individuelle pour chaque élément d'entrée.

Un résultat de niveau champ remplit l'élément d'entrée associé de la manière suivante :

• Si l'interprétation est un résultat simple, on affecte celui-ci à la variable d'élément d'entrée.
• Si l'interprétation est une structure et que le nom de facette correspond à une propriété, alors on affecte la valeur de cette propriété à la variable d'élément d'entrée.
• Sinon, on affecte le résultat sémantique entier.

Ce processus permet à un élément d'entrée d'extraire une propriété particulière d'une interprétation sémantique. On peut le combiner avec un élément filled pour obtenir un contrôle encore plus précis :

<field name="getdate">
  <prompt>Quand voulez-vous voler ?</prompt>

  <grammar src="http://serveur.example.com/date.grxml"/>
  <!-- Cette grammaire renvoie toujours un objet contenant
       des valeurs de chaîne pour les propriétés day, month et year -->

  <filled>
    <assign name="getdate.datestring" 
            expr="getdate.year + getdate.month + getdate.day"/>
  </filled>
</field>

3.1.6.3 Autres exemples

Un nom de facette avéré permet à un élément d'entrée d'extraire une partie d'une interprétation sémantique. Prenons ce résultat modifié inspiré de l'exemple précédent :

application.lastresult$.interpretation =
{ boisson: { taille: 'grande', liquide: 'eau' },
  pizza: { quantite: '3', taille: 'grande',
           garniture: ['poivron', 'champignon'] }, 
  accompagnement: undefined
}

Le tableau suivant revoit la définition du moment où le nom de facette correspond à une propriété dans le résultat :

On peut aussi comparer les comportements des résultats de niveau formulaire et ceux de niveau champ. Pour cela, prenons le document suivant :

<?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="exempleFormulaire">
      <grammar src="niveauformulaire.grxml"/>
      <initial> Dites quelque chose. </initial>

      <field name="x">
        <grammar src="fieldx.grxml"/>
      </field>

      <field name="z" slot="y">
        <grammar src="fieldz.grxml"/>
      </field>
    </form>
  </vxml>

Cet exemple définit deux variables d'élément d'entrée : x et z. Les noms de facette correspondant sont respectivement x et y. Le tableau suivant décrit l'affectation de ces variables selon la grammaire reconnue et le résultat sémantique renvoyé. Le raccourci valeurX signifie la valeur de résultat simple ou d'objet structuré associée à la propriété x.

Au niveau du formulaire, les résultats simples comme la chaîne bonjour ne correspondent à aucun des éléments d'entrée ; les objets structurés affectent toutes les variables d'éléments d'entrée avec les noms de facette correspondants. Au niveau du champ, les résultats simples sont toujours affectés à la variable d'élément d'entrée ; les objets structurés extraieront la propriété correspondante, si elle existe, sinon, le résultat sémantique entier sera assigné à la variable d'élément d'entrée.

3.1.6.4 Autres problèmes

1. L'application depuis une sémantique en langue naturelle vers ECMAScript :
Si on se sert du langage de balisage sémantique en langue naturelle ([NLSML]), il faudra définir une application depuis la représentation NLSML vers des objets ECMAScript. Les deux types de représentation ayant des structures imbriquées similaires, cette application est assez directe. La spécification NLSML explique en détails cette application.

2. Le passage des résultats sémantiques de la reconnaissance vocale automatique à VoiceXML :
Le résultat du traitement des balises sémantiques d'une grammaire de reconnaissance vocale automatique du W3C correspond à la valeur de l'attribut de la règle racine une fois que toutes les évaluations des rattachements sémantiques ont été effectuées. En outre, la règle racine (comme tous les non-terminaux) possède une variable text associée qui contient les séries d'atomes de l'énoncé régi par ce non-terminal. Dans le processus de mise à disposition des résultats de la reconnaissance vocale automatique aux documents VoiceXML, la plateforme VoiceXML n'est pas seulement responsable du remplissage des champs VoiceXML en fonction de la valeur de l'attribut de la règle racine, comme décrit précédemment, mais aussi du remplissage des variables fictives de ces champs. La valeur de la variable fictive nom$.utterance du champ devrait être la même que celle de la variable text de la règle racine de la reconnaissance vocale automatique. La plateforme est également responsable de l'instanciation de la valeur de la variable fictive nom$.confidence qui dépend des informations fournies par la plateforme de reconnaissance vocale automatique, ainsi que de la variable nom$.inputmode selon qu'il s'agissait d'un traitement vocal ou DTMF. Enfin, elle est responsable de la mise en place de ces informations dans le tableau application.lastresult$, définie dans le chapitre 5.1.5 (particulièrement, les variables application.lastresult$.utterance, application.lastresult$.inputmode et application.lastresult$.interpretation), à l'exception de la variable application.lastresult$.confidence, dont la plateforme fixe la valeur comme étant la valeur de fiabilité de l'interprétation de l'énoncé entier.

3. Les contradictions entre les résultats sémantiques et les champs VoiceXML :
L'application des résultats sémantiques à VoiceXML s'appuie sur une coordination étroite entre la grammaire de reconnaissance vocale automatique et le balisage VoiceXML. Étant donné que rien, dans le présent cadre, ne vient faire respecter la cohérence entre une grammaire et le dialogue VoiceXML associé, il peut survenir des contradictions du fait de l'inattention du développeur. Comme il est difficile de distinguer le comportement du dialogue en présence de ces contradictions de celui dans certaines situations normales, il est extrêmement important de vérifier la cohérence des informations. Quelques exemples de contradictions :

• Les résultats sémantiques contiennent des informations supplémentaires qui ne correspondent pas aux champs VoiceXML. Cela peut se produire à cause d'une erreur du développeur ou à cause de l'emploi d'une grammaire plus riche que ce qui est demandé par l'application VoiceXML. Ces informations supplémentaires seront ignorées.
• L'application VoiceXML attend du résultat des informations manquantes. Cela peut également venir d'une erreur du développeur ou du fait que l'utilisateur n'a simplement pas fourni la valeur d'une facette particulière. Auquel cas, l'algorithme FIA poursuit normalement et la valeur manquante sera demandée à l'utilisateur. Si le problème était en fait causé par une erreur du développeur et que la grammaire est effectivement incapable de reconnaître la valeur correcte, l'algorithme FIA continuera à demander la valeur manquante jusqu'à tant qu'il invoque les mesures que la plateforme et l'application ont mis en place en cas d'échecs de correspondance répétés.
• Enfin, les informations peuvent être présentes à la fois dans les champs VoiceXML et dans le résultat de la reconnaissance vocale automatique mais dans des formats incompatibles. Par exemple, une grammaire de reconnaissance vocale automatique pourrait fournir un objet structuré à propos d'une boisson, comprenant la taille de cette boisson et une indication selon laquelle celle-ci est diététique ou non, mais le formulaire VoiceXML prévoit seulement une chaîne composant le nom de la boisson. Dans ces situations, le comportement du système dépendra de ce qui est fait des résultats. Par exemple, l'objet structuré peut avoir été transmis à un script côté serveur qui attend une chaîne, et les conséquences dépendraient alors du script côté serveur.

Afin de répondre à ces problèmes potentiels, le comité examine diverses approches permettant de garantir une certaine cohérence entre la grammaire et les champs VoiceXML.

4. La sortie du système

4.1 Les invites

L'élément prompt contrôle la sortie de la voix synthétisée et des sons préenregistrés. Conceptuellement, les invites sont instantanément mises en file d'attente de lecture, de sorte que l'interprétation se poursuit jusqu'au point où l'utilisateur doive fournir une entrée. Les invites sont alors jouées et le système attend une entrée d'utilisateur. Une fois l'entrée reçue du sous-système de reconnaissane vocale (ou du logiciel de reconnaissance DTMF), l'interprétation se poursuit.

L'élément prompt a les attributs suivants :

4.1.1 Le balisage de la parole

Le modèle du contenu de l'élément prompt se fonde sur le langage de balisage de la synthèse vocale (SSML) 1.0 [SSML].

Les éléments de balisage de la parole suivants sont définis dans la spécification [SSML] et disponibles dans VoiceXML 2.0. Voir les définitions et les exemples dans le langage de balisage de la synthèse vocale 1.0 [SSML].

Lorsqu'on les utilise dans VoiceXML, les éléments audio (voir le chapitre 4.1.3) et say-as (voir l'annexe P) acceptent d'autres propriétés. Le langage VoiceXML admet également la présence des éléments enumerate et value dans les éléments prompt.

La plateforme VoiceXML doit être un processeur SSML conforme comme défini par la spécification [SSML]. Bien que cette définition exige d'une plateforme qu'elle puisse traiter des documents ayant un ou plusieurs attributs xml:lang, elle n'exige pas qu'elle soit multilingue. Lorsqu'elle rencontre une langue non reconnue, la plateforme suscite un événement error.unsupported.language indiquant quelle langue n'est pas reconnue dans sa variable message.

4.1.2 Les invites de base

Nous avons vu des invites dans les exemples précédents :

<prompt>Veuillez dire le nom de votre ville.</prompt>

On peut abandonner le balisage <prompt> ... </prompt> si ::

• Il n'est pas nécessaire de définir un attribut d'invite (comme l'attribut bargein), et

• L'invite se compose entièrement de texte de type PCDATA (c'est-à-dire, qui ne contient pas de balises vocales) ou bien juste d'un élément audio ou value.

Par exemple, il existe aussi des invites ayant cet aspect :

Veuillez dire le nom de votre ville.

<audio src="dis_ta_ville.wav"/>

Dans cet exemple, cependant, les balises englobantes de l'élément prompt sont obligatoires en raison de la présence de balises vocales :

<prompt>Veuillez <emphasis>dire</emphasis> le nom de votre ville.</prompt>

Lorsqu'on indique un contenu d'invite sans utilisation explicite d'un élément prompt, alors les attributs de l'invite se définissent comme indiqué dans le tableau 34.

4.1.3 L'invite sonore

Les invites peuvent se composer de n'importe quelle combinaison de fichiers préenregistrés, flux audio ou voix synthétisée :

<prompt>
   Bienvenue chez Graines à gogo.
   <audio src="rtsp://www.piafcauserie.example.com/grive.wav"/>
   Ce mois-ci nous proposons le barril de 250 kg de graines de chardon à
   <say-as interpret-as="currency">299.95€</say-as>

   frais d'expédition et de transport compris.
   <audio src="http://www.piafcauserie.example.com/tourterelle.wav"/>
</prompt>

On peut jouer un son dans n'importe quelle invite. On peut indiquer le contenu sonore via une adresse URI et aussi, dans VoiceXML, dans un élément audio enregistré précédemment :

<prompt>
   Votre message d'accueil enregistré est
   <audio expr="accueil"/>
   Pour le réenregistrer, tapez 1.
   Pour le conserver, tapez dièse.
   Pour revenir au menu principal, tapez étoile M.
   Pour quitter, tapez étoile, étoile Q.
</prompt>

L'élément audio peut comporter un contenu de remplacement au cas où l'échantillon audio ne serait pas disponible :

<prompt>
   <audio src="bienvenue.wav"> 
     <emphasis>Bienvenue</emphasis> sur le portail vocal. 
   </audio>
</prompt>

Si le fichier son est injouable (par exemple, à cause d'attributs src ou expr se résolvant en une adresse URI invalide, d'un fichier dans un format non reconnu, etc.), alors le contenu de l'élément audio sera joué à la place. Ce contenu peut comprendre du texte, du balisage vocal ou un autre élément audio. Si le fichier son est injouable et que le contenu de l'élément audio est vide, aucun son ne sera joué et aucun événement d'erreur ne sera suscité.

Si l'élément audio contient un attribut expr évalué à la valeur ECMAScript "undefined", alors l'élément, y compris son contenu de remplacement, sera ignoré. Cela permet au développeur de définir des éléments audio ayant un contenu assigné dynamiquement qui, si on ne les demande pas, peuvent être ignorés en assignant une valeur nulle à leur attribut expr. Par exemple, le code suivant montre comment se servir de cette caractéristique pour lire une main de cartes au moyen de clips audio concaténés :

<?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>
  <!-- Le script contient la fonction direCarte(type,position)
       qui reçoit en entrée le type de la description de carte (son ou texte) et
       sa position dans un tableau, et renvoie la description de carte
       sélectionnée à la position indiquée dans le tableau ;
       s'il n'y a pas de description à la position demandée, alors elle renvoie
       la valeur ECAMScript "undefined"
  --> 
  
  <script src="jeudecartes.js"/>

  <field name="prendrecarte">
       <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
       <prompt>
           <audio src="vous_avez.wav">Vous avez les cartes suivantes : </audio>
           <!-- on décrit une main de 5 cartes au maximum -->
           <audio expr="direCarte(son,1)"><value expr="direCarte(texte,1)"/></audio>
           <audio expr="direCarte(son,2)"><value expr="direCarte(texte,2)"/></audio>
           <audio expr="direCarte(son,3)"><value expr="direCarte(texte,3)"/></audio>
           <audio expr="direCarte(son,4)"><value expr="direCarte(texte,4)"/></audio>
           <audio expr="direCarte(son,5)"><value expr="direCarte(texte,5)"/></audio>
           <audio src="une_autre.wav">Voulez-vous une autre carte ? </audio>
        </prompt>
        <filled>
              <if cond="prendre">
                  <script>prendreAutreCarte()</script>
                  <clear/>
              <else/>
                  <goto next="./parier.vxml"/>
              </if>
        </filled>
   </field>
</form>
</vxml>

Les attributs de l'élément audio définis dans la spécification [SSML] sont :

Les attributs de l'élément audio seulement définis dans VoiceXML sont :

On ne peut définir qu'un seul exactement entre les attributs src ou expr, sinon, un événement error.badfetch sera suscité.

Remarquez que la lecture du son en continu est une optimisation apportée par la plateforme, c'est-à-dire que la plateforme peut commencer le traitement du contenu audio au fur et à mesure qu'il parvient et ne pas attendre son chargement complet. On peut se servir de l'attribut de préchargement fetchhint pour demander le chargement complet du son avant lecture.

4.1.4 L'élément value

L'élément value sert à insérer la valeur d'une expression dans une invite. Il a un seul attribut :

Par exemple, si la variable n vaut "12" dans cette invite :

<prompt>
  <value expr="n*n"/> est le carré de <value expr="n"/>.
</prompt>

Alors le moteur de synthèse vocale recevra la phrase 144 est le carré de 12.

La façon dont l'attribut de l'élément value jouera se trouve sous le contrôle du balisage de synthèse vocale environnant. Par exemple, la valeur peut être jouée comme une date :

<var name="date" expr="'2000/1/20'"/>
<prompt>
    <say-as interpret-as="date">
        <value expr="date"/>
    </say-as>
</prompt>

Le texte inséré par l'élément value ne fait pas l'objet d'une interprétation particulière et, notamment, il n'est pas analysé en tant que document ou fragment de document [SSML]. Les caractères spéciaux XML (&, > et <) ne sont pas non plus traités spécialement et ils n'ont pas besoin d'être masqués. On obtiendra la même chose en insérant littéralement le texte calculé par l'élément value dans une section de type CDATA. Par exemple, l'assignation de variable suivante :

<script> 
    <![CDATA[ 
        e1 = 'AT&T';
    ]]>
</script> 

Si on l'appelle dans un élément prompt comme :

  <prompt> L'action <value expr="e1"/> vaut 1€. </prompt>

Voici alors la sortie produite .

 L'action AT&T vaut 1€.

4.1.5 L'interruption

Lorsqu'une plateforme d'implémentation gère les interruptions, l'auteur de l'application peut indiquer si l'utilisateur peut interrompre [Ndt. to bargein] une invite par une commande vocale ou DTMF. Cette caractéristique permet d'accélérer la conversation mais elle n'est pas toujours souhaitée. Si l'auteur de l'application exige de l'utilisateur qu'il entende la totalité d'un avertissement, d'un avis légal ou d'une publicité, il faudrait désactiver l'interruption. C'est le rôle de l'attribut bargein :

<prompt bargein="false"><audio src="avis_legal.wav"/></prompt>

Les utilisateurs peuvent interrompre une invite dont la valeur de l'attribut bargein est "true" et ils doivent, au contraire, attendre la fin de l'invite pour la valeur "false". Au cas où plusieurs invites sont en file d'attente, c'est l'attribut bargein de chaque invite qui régit la période pendant laquelle l'invite concernée est jouée. Si une interruption se produit au cours de n'importe quelle invite d'une séquence, alors aucune des invites suivantes n'est jouée (même celles dont l'attribut bargein vaut "false". Si l'attribut bargein n'est pas défini, alors c'est la valeur de la propriété bargein qui sera utilisée, si elle est fixée.

Lorsque la valeur de l'attribut bargein est "false, alors l'entrée n'est pas mise en mémoire tampon pendant la lecture de l'invite et toute entrée DTM tamponnée dans un état transitoire est effacée du tampon (le chapitre 4.1.8 décrit la collecte des entrées pendant les états transitoires).

Remarquez que les moteurs de reconnaissance vocale et les plateformes d'implémentation ne gère pas tous l'interruption. Pour qu'une plateforme puisse gérer les interruptions, elle doit reconnaître au moins l'un des types d'interruption décrits dans le chapitre 4.1.5.1.

4.1.5.1 Le type d'interruption

Quand l'interruption est permise, on peut se servir de l'attribut bargeintype pour suggérer le type d'interruption que la plateforme effectuera en réponse à une commande vocale ou DTMF. Les valeurs possibles de cet attribut sont :

Lorsque l'attribut bargeintype n'est pas défini, alors on utilise la valeur de la propriété bargeintype. Les implémentations prétendant gérer les interruptions sont obligées de gérer au moins l'un de ces deux types. La présence simultanée de ces types dans la même file d'attente d'invites est susceptible d'entraîner un comportement imprévisible, cette pratique n'est donc pas encouragée.

Quand l'attribut bargeintype a la valeur "speech", le sens exact du terme commande vocale dépend forcément de l'implémentation, en raison de la complexité de la technologie de reconnaissance vocale. On s'attend à ce que l'invite s'arrête dès lors que la plateforme peut déterminer avec certitude que l'entrée est vocale. Il est souhaitable d'arrêter l'invite aussitôt que possible ce qui permet d'éviter l'effet de bégaiement selon lequel l'utilisateur s'arrête à mi-énoncé et recommence en croyant que le système ne l'a pas entendu.

4.1.6 La sélection d'une invite

Les invites dégressives sont celles susceptibles de changer à chaque invite. Les invites appelant un renseignement peuvent devenir de plus en plus abruptes, à supposer que l'utilisateur se familiarise avec la tâche. Les messages d'erreur peuvent devenir plus détaillés, à supposer que l'utilisateur a besoin d'assistance. Ou bien les invites peuvent tout simplement changer pour rendre l'interaction plus intéressante.

Tous les élément d'entrée, l'élément initial et l'élément menu intègre un compteur d'invites qui est réinitialisé à la valeur "1" à chaque accès au formulaire ou au menu. Dès lors que le système sélectionne un élément d'entrée donné au cours de la phase de sélection de l'algorithme FIA, dans laquelle il détermine la sélection et la mise en file d'attente normales des invites (c'est-à-dire que, comme décrit dans le chapitre 5.3.6, l'itération précédente de l'algorithme FIA n'a pas terminé sur un gestionnaire de capture qui ne comportait pas d'élément reprompt), le compteur d'invites associé à l'élément en question est incrémenté. Tel est le mécanisme qui sous-tend les invites dégressives.

Par exemple, voici un formulaire avec une invite de niveau formulaire et des invites de niveau champ :

<?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="degressif">
  <block>
    <prompt bargein="false">
      Bienvenue dans l'enquête sur la consommation des glaces.
    </prompt>
  </block>
  <field name="parfum">
  <grammar mode="voice" version="1.0" root="racine">
    <rule id="racine" scope="public">
      <one-of>
        <item>vanille</item>
        <item>chocolat</item>
        <item>fraise</item>
     </one-of>
    </rule>
   </grammar>
   <prompt count="1">Quel est votre parfum favori ?</prompt>
   <prompt count="3">Dites chocolat, vanille ou fraise.</prompt>
   <help>Désolé, on ne peut pas vous aider.</help>
  </field>
</form>
</vxml>

Et maintenant, une conversation utilisant ce formulaire :

O : Bienvenue dans l'enquête sur la consommation des glaces.

O : Quel est votre parfum favori ? (la valeur du compteur d'invites du champs parfum est "1")

H : Pécan praline.

O : Je ne comprends pas.

O : Quel est votre parfum favori ? (la valeur du compteur d'invites est maintenant de "2")

H : Pécan praline.

O : Je ne comprend pas.

O : Dites chocolat, vanille ou fraise. (la valeur du compteur est "3")

H : Et si je déteste ces parfums ?

O : Je ne comprends pas.

O : Dites chocolat, vanille ou fraise. (la valeur du compteur est "4")

H : ...

Cet exemple illustre juste l'emploi des compteurs d'invites. Un formulaire plus fin offrirait un éventail de choix plus complet et traiterait les valeurs hors définition de manière plus souple.

À l'instant de sélectionner une invite, le compteur d'invites est examiné. C'est la sous-invite dont la valeur de l'attribut count est inférieure ou égale à celle du compteur d'invites qui est retenue. Si une invite n'a pas d'attribut count, alors le compteur est censé avoir la valeur "1".

Une invite conditionnelle est celle qui est dite seulement si sa condition est satisfaite. Dans cet exemple, l'invite varie à chaque visite du formulaire englobant :

<?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="autre_blague">
   <var name="r" expr="Math.random()"/>
   <field name="autre">
       <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
       <prompt cond="r &lt; .50">
          Voulez-vous entendre une autre blague sur les éléphants ?
       </prompt>
       <prompt cond="r &gt;= .50">
         Pour une autre blague, dites oui. Pour quitter, dites non
       </prompt>
       <filled>
          <if cond="autre">
            <goto next="#choisir_blague"/>
          </if>
       </filled>
   </field>
</form>
</vxml>

Au moment de choisir une invite, l'ensemble des invites à placer en file d'attente est établi en fonction de l'algorithme suivant :

1. Former une liste ordonnée des invites, se composant de toutes les invites dans l'élément englobant, dans l'ordre du document.
2. Supprimer de cette liste toutes les invites dont la valeur de l'attribut cond, après conversion en un booléen, est "false".
3. Trouver le compte correct : la valeur d'attribut count la plus élevée, parmi les éléments prompt encore présents sur la liste, qui soit inférieure ou égale à la valeur d'attribut count courante.
4. Supprimer de la liste tous les éléments qui n'ont pas le compte correct.

Tous les éléments restant sur la liste seront mis en file d'attente pour lecture.

4.1.7 La temporisation

L'attribut timeout indique l'intervalle de silence permis à attendre l'entrée d'utilisateur après la fin de la dernière invite. Si cet intervalle est dépassé, la plateforme suscitera un événement noinput. La valeur implicite de cet attribut est celle indiquée par la propriété timeout (voir le chapitre 6.3.4) à l'instant où l'invite est placée en file d'attente. En d'autres termes, chaque invite a sa propre valeur de temporisation.

La raison de permettre la définition d'une temporisation comme attribut de l'élément prompt tient dans les temporisations dégressives. Par exemple, l'utilisateur peut disposer de cinq secondes pour la première tentative d'entrée puis de dix secondes pour la suivante.

La temporisation de l'élément prompt détermine celle de l'événement noinput de l'entrée suivante :

<prompt count="1">
  Choisissez la couleur de votre nouveau modèle T.
</prompt>

<prompt count="2" timeout="120s">
  Veuillez choisir la couleur de votre nouvelle Ford modèle T de mille neuf cent vingt-quatre.
  Les couleurs possibles : noire, noire ou noire. Prenez votre temps.
</prompt>

Si plusieurs invites sont placées en file d'attente avant une entrée de champ, alors c'est la temporisation de la dernière invite qui est utilisée.

4.1.8 La mise en file d'attente des invites et la collecte des entrées

Un interpréteur VoiceXML se trouve, à tout instant, dans l'un des états suivants :

• en attente d'une entrée dans un élément d'entrée (tels que field, record ou transfer), ou
• en transition entre deux éléments d'entrée suite à une entrée (comprenant les énoncés prononcés, les appuis de touche DTMF et les événements liés aux entrées tels que les événements noinput ou nomatch) reçue dans l'état d'attente. Dans l'état de transition, aucune commande vocale n'est collectée ni acceptée ni interprétée. Par conséquent, les grammaires vocales de niveau racine et document (comme celles définies dans les éléments link peuvent ne pas être tout le temps actives. Au contraire, les commandes DTMF (y compris les informations de temporisation) dans l'état de transition devraient être collectées et mises en mémoire tampon. De même, les événements asynchrones qui ne sont pas directement liés à l'exécution de la transition devraient également être mis en mémoire tampon jusqu'à l'état d'attente suivant (par exemple, un événement connection.disconnect.hangup).

Les états d'attente et de transition sont reliés aux phases de l'algorithme FIA comme suit :

• l'interpréteur entre finalement en état d'attente lors de la phase de collecte d'un élément d'entrée (au point où l'interpréteur attend une entrée), et
• l'état de transition engloble les phases de traitement et de sélection, la phase de collecte des éléments de commande (tels que les éléments block) et la phase de collecte des éléments d'entrée jusqu'au point où l'interpréteur attend une entrée.

Cette distinction des états est destinée à clarifier le modèle de programmation. En particulier, une conséquence importante de ce modèle est celle selon laquelle le développeur de l'application VoiceXML peut compter sur l'exécution complète de tout le contenu exécutable (tel que le contenu des éléments filled et block), parce qu'elle intervient pendant l'état de transition lequel ne peut être interrompu par une entrée.

Pendant l'état de transition, les diverses invites sont placées en file d'attente soit par l'élément prompt dans un contenu exécutable, soit par l'élément prompt dans des éléments de formulaire. En outre, un son d'attente peut être placé en file d'attent par l'attribut fetchaudio. Les invites et le son d'attente dans la file d'attente sont joués :

• soit quand l'interpréteur atteint l'état d'attente, point à partir duquel les invites sont jouées, l'interpréteur étant à l'écoute d'une entrée qui corresponde à l'une des grammaires actives,
• soit quand l'interpréteur commence le chargement d'une ressource (tel qu'un document) pour lequel un attribut fetchaudio a été défini. Auquel cas, les invites placées en file d'attente, avant le son d'attente indiqué par l'attribut fetchaudio, sont jouées jusqu'au bout puis, si la ressource doit réellement être chargée (c'est-à-dire que le délai de sa mise en cache a expiré), alors le son d'attente fetchaudio joue jusqu'à la fin du chargement. L'interpréteur reste dans l'état de transition et aucune entrée n'est acceptée au cours du chargement.

Remarquez que, lorsque la valeur de l'attribut bargein d'un élément prompt est "false", les entrées ne sont pas collectées et les commandes DTMF mises en mémoire tampon pendant un état de transition sont effacées (voir le chapitre 4.1.5).

Lorsqu'une grammaire de reconnaissance vocale automatique correspond, si une commande DTMF a été simultanément consommée par une grammaire DTMF (sans que cela ait abouti à une correspondance complète à la grammaire DTMF), alors le processeur peut choisir d'écarter la commande DTMF.

Avant que l'interpréteur ne quitte, toutes les invites en file d'attente sont jouées jusqu'au bout. L'interpréteur reste dans l'état de transition et aucune entrée n'est acceptée tant que l'interpréteur n'a pas quitté.

L'optimisation selon laquelle les invites commencent à jouer pendant l'état de transition avant d'atteindre l'état d'attente est permise, à condition de maintenir une sémantique correcte vis-à-vis du traitement de l'entrée audio reçue pendant la lecture des invites, par exemple, en ce qui concerne les traitements des interruptions et des grammaires.

Les exemples suivants illustrent la mise en œuvre de ces règles dans quelques cas communs.

Cas 1

Cas de non-chargement typique : un élément field, suivi par un contenu exécutable (tels que des éléments block ou filled), suivi par un autre élément field.

 dans le document d0

    <field name="f0"/>

    <block>
        contenu exécutable e1
        met les invites {p1} en file d'attente
    </block>

    <field name="f2">
        met les invites {p2} en file d'attente
        active les grammaires {g2}
    </field>

En conséquence d'une entrée reçue en cours d'attente dans le champ f0, voici les actions qui sont entreprises :

• dans l'état de transition :
  • exécuter e1 (sans élément goto)
  • mettre les invites {p1} en file d'attente
  • mettre les invites {p2} en file d'attente
• simultanément, dans l'état d'attente :
  • jouer les invites {p1,p2}
  • activer les grammaires {g2} et attendre une entrée

Cas 2

Cas de chargement typique : un élément field, suivi par un contenu exécutable (tels que des éléments block ou filled) qui se termine par un élément goto définissant un attribut fetchaudio et qui aboutit dans un élément field d'un autre document chargé d'un serveur.

 dans le document d0

    <field name="f0"/>

    <block>
        contenu exécutable e1
        met les invites {p1} en file d'attente
        mène au champ f2 dans le document d1 avec un son d'attente fa
    </block>

dans le document d1

    <field name="f2">
        met les invites {p2} en file d'attente
        active les grammaires {g2}
    </field>

En conséquence d'une entrée reçue en cours d'attente dans le champ f0, voici les actions qui sont entreprises :

• dans l'état de transition :
  • exécuter e1
  • mettre les invites {p1} en file d'attente
  • simultanément :
    • charger le document d1
    • jouer les invites {p1} jusqu'au bout puis jouer le son d'attente fa jusqu'à la fin du chargement
  • mettre les invites {p2} en file d'attente
• simultanément, dans l'état d'attente :
  • jouer les invites {p2}
  • activer les grammaires {g2} et attendre une entrée

Cas 3

Comme dans le cas 2, mais sans attribut fetchaudio défini.

 dans le document d0

    <field name="f0"/>

    <block>
        contenu exécutable e1
        met les invites {p1} en file d'attente
        mène au champ f2 dans le document d1 (sans son d'attente)
    </block>

dans le document d1

    <field name="f2">
        met les invites {p2} en file d'attente
        active les grammaires {g2}
    </field>

En conséquence d'une entrée reçue en cours d'attente dans le champ f0, voici les actions qui sont entreprises :

• dans l'état de transition :
  • exécuter e1
  • mettre les invites {p1} en file d'attente
  • charger le document d1
  • mettre les invites {p2} en file d'attente
• simultanément, dans l'état d'attente :
  • jouer les invites {p1, p2}
  • activer les grammaires {g2} et attendre une entrée

5. Le flux de commande et les scripts

5.1 Les variables et les expressions

Les variables VoiceXML sont à tous égards équivalentes aux variables ECMAScript : elles font partie du même espace de variables. Les variables VoiceXML peuvent servir dans un élément script tout comme les variables définies dans un élément script peuvent servir dans un document VoiceXML. Déclarer une variable au moyen de l'élément var équivaut à utiliser une déclaration var dans un élément script. L'élément script peut aussi apparaître partout où l'élément var peut apparaître. Les éléments de formulaire peuvent également déclarer des variables VoiceXML.

Les conventions de nommage des variables sont les mêmes que dans ECMAScript, hormis les noms commençant par un caractère souligné (_) et ceux finissant par un caractère signe dollar ($) qui sont réservés pour un usage interne. Les variables VoiceXML, y compris les variables d'élément de formulaire, ne doivent pas contenir de mots réservés pour ECMAScript. Elles doivent aussi respecter les règles ECMAScript de correction référentielle. Par exemple, les noms de variable doivent être uniques et leur déclaration ne doit pas contenir de point (var x.y est une déclaration illégale dans ECMAScript. Les noms de variable qui violent les conventions de nommage ou bien les règles ECMAScript provoquent un événement error.semantic.

5.1.1 La déclaration des variables

On déclare les variables au moyen d'éléments var :

<var name="tel_domicile"/> 
<var name="pi" expr="3.14159"/> 
<var name="ville" expr="'Périgueux'"/>

Elles peuvent aussi être déclarés par les éléments de formulaire :

<field name="nbre_tickets"> 
   <grammar type="application/srgs+xml" src="/grammars/number.grxml"/>
   <prompt>Combien voulez-vous acheter de tickets?</prompt> 
</field>

Les variables déclarées sans valeur initiale explicite sont initialisées à la valeur ECMAScript "undefined". On doit déclarer les variables avant de les utiliser, dans VoiceXML comme dans ECMAScript. L'utilisation d'une variable non déclarée se traduit par une erreur ECMAScript qui transparaît comme un événement error.semantic. On peut utiliser les variables déclarées dans ECMAScript au moyen du mot-clé var dans VoiceXML, tout comme on peut utiliser les variables VoiceXML dans ECMAScript.

Dans un formulaire, les variables déclarées par des éléments var et celles déclarées par des éléments de formulaire sont initialisées lorsqu'on accède au formulaire. Les initialisations sont assurées de survenir dans l'ordre du document, de sorte que cet exemple est légal :

<?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="test"> 
   <var name="un" expr="1"/> 
   <field name="deux" expr="un+1">
     <grammar type="application/srgs+xml" src="/grammars/number.grxml"/>
   </field> 
   <var name="trois" expr="deux+1"/> 
   <field name="continuer" type="boolean"> 
     <prompt>Dites oui ou non pour continuer</prompt> 
   </field> 
</form>
</vxml>

Lorsque l'utilisateur visite cet élément form, l'initialisation du formulaire établit d'abord la variable un et fixe sa valeur à "1". Puis c'est le tour de la variable deux avec une valeur de "2". Ensuite, la logique d'initialisation déclare la variable trois et lui donne la valeur "3". L'algorithme FIA entre alors dans l'interprétation de sa boucle principale et commence au champ continuer.

5.1.2 Les portées des variables

Le langage VoiceXML utilise une chaîne de portées ECMAScript qui permet de déclarer des variables à des niveaux hiérarchiques différents dans une application. Par exemple, une variable déclarée avec une portée de document peut être appelée depuis n'importe où dans ce document, tandis qu'une variable locale déclarée dans un élément catch ne sera visible que dans cet élément catch. Pour conserver cette sémantique de visibilité, on doit déclarer toutes les variables ECMAScript. L'utilisation d'une variable non déclarée se traduit par une erreur ECMAScript qui transparaît via un événement error.semantic.

On peut déclarer les variables avec les portées suivantes :

Le diagramme suivant illustre la hiérarchie des portées :

Figure 11 : La hiérarchie des portées

Les flèches courbes dans ce diagramme montre que chaque portée contient une variables prédéfinie dont le nom est le même que celui qui se rapporte à la portée en question. Cela permet, par exemple, dans les portées anonymes, dans celles de dialogue et celles de document, d'appeler une variable X dans la portée de document en faisant document.X. Comme autre exemple, la portée des variables d'un élément filled est une portée anonyme locale à l'élément filled dont la portée des variables du parent est celle de l'élément form.

On décourage l'emploi des mots session, application, document et dialog comme noms des variables et des éléments de formulaire. Bien que ce ne soient pas des mots réservés, les employer éclipse les variables prédéfinies de même nom à cause des règles de portée ECMAScript utilisées par VoiceXML.

5.1.3 L'appel des variables

Les variables sont appelées par les attributs cond et expr :

<if cond="aeroport == 'LAX'"> 
   <assign name="aeroport" expr="'Los Angeles'"/> 
<elseif cond="aeroport == 'PPT'"/> 
   <assign name="aeroport" expr="'Papeete'"/> 
<elseif cond="aeroport =='PGX'"/> 
   <assign name="aeroport" expr="'Périgueux'"/> 
</if> 

<assign name="var1" expr="var1 + 1"/> 

<if cond="i &gt; 1"> 
   <assign name="i" expr="i-1"/> 
</if>

Le langage utilisé dans les expressions des attributs cond et expr est précisément ECMAScript. Remarquez qu'on doit masquer les opérateurs de l'attribut cond <, <= et && dans XML (en &lt;, &lt;=, etc.).

Les appels des variables s'inscrivent dans la portée englobante la plus proche selon la chaîne des portées donnée précédemment. On peut préfixer un appel avec un nom de portée pour raison de clarté ou afin de résoudre une ambiguïté. Par exemple, afin de sauvegarder la valeur d'une variable associée à l'un des champs d'un formulaire pour une utilisation ultérieure dans un document :

<assign name="document.ssn" expr="dialog.ssn"/>

Si le document racine d'application contient une variable x, on l'appelle par application.x dans les documents non-racine, et par application.x ou bien document.x dans le document racine d'application. Si le document ne définit pas d'application racine et contient une variable x, on l'appelle soit par application.x, soit par document.x dans le document.

5.1.4 Les variables de session normalisées

session.connection.local.uri

Cette variable est une adresse URI qui désigne l'appareil du contexte d'interprétation.

session.connection.remote.uri

Cette variable est une adresse URI qui désigne l'appareil appelant distant.

session.connection.protocol.name

Cette variable correspond au nom du protocole de connexion. Le nom représente également le nom de sous-objet des informations propres au protocole. Par exemple, si la variable session.connection.protocol.name vaut "q931", alors la variable session.connection.protocol.q931.uui est susceptible de définir la propriété d'information utilisateur-à-utilisateur de la connexion.

session.connection.protocol.version

Cette variable correspond à la version du protocole de connexion.

session.connection.redirect

Cette variable est un tableau représentant les chemins des redirections de connexion. Le premier élément correspond au numéro original appelé et le dernier élément au dernier numéro redirigé. Chaque élément du tableau contient une propriété uri, pi (information de présentation, si (information de filtrage) et reason. La propriété reason admet l'une des valeurs suivantes : "unknown", "user busy", "no reply", "deflection during alerting", "deflection immediate response" ou "mobile subscriber not reachable".

session.connection.aai

Cette variable correspond à des informations interapplications transmises pendant l'établissement de la connexion.

session.connection.originator

Cette variable appelle directement soit la propriété local, soit la propriété remote (par exemple, l'expression ECMAScript suivante renverra la valeur "true" si le tiers distant a initié la connexion : var appelant_initiateur = connection.originator == connection.remote).

5.1.5 Les variables d'application normalisées

application.lastresult$

Cette variable contient des informations concernant la dernière reconnaissance qui a eu lieu dans cette application. C'est un tableau d'éléments dont lequel chaque élément application.lastresult$[i] représente un résultat possible au travers des variables suivantes :

application.lastresult$[i].confidence

Le niveau de fiabilité de l'énoncé entier de cette interprétation dans l'intervalle 0.0-1.0. Une valeur de "0.0" indique une fiabilité minimale et une valeur de "1.0" une fiabilité maximale. L'interprétation plus précise d'une valeur de fiabilité dépendra de la plateforme.

application.lastresult$[i].utterance

La chaîne des mots bruts qui ont été reconnus pour cette interprétation. L'atomisation et l'orthographe exactes sont propres à la plateforme (par exemple, cinq cent trente ou 5 cent 30 ou même 530). Dans le cas d'une grammaire DTMF, cette variable contiendra la chaîne numérique reconnue.

application.lastresult$[i].inputmode

Pour cette interprétation, le mode selon lequel l'entrée d'utilisateur a été fournie : "dtmf" ou "voice".

application.lastresult$[i].interpretation

Une variable ECMAScript contenant l'interprétation, comme décrit dans le chapitre 3.1.5.

Les interprétations sont triées par score de fiabilité, du plus grand au plus petit. Celles ayant le même score de fiabilité font l'objet d'un tri supplémentaire en fonction des relations de préséance (voir le chapitre 3.1.4) entre les grammaires produisant les interprétations. Des éléments différents dans le tableau application.lastresult$ différeront toujours par leur énoncé, leur interprétation, ou les deux.

Le nombre d'éléments du tableau application.lastresult$ est assuré supérieur ou égal à un et inférieur ou égal à la valeur de la propriété de système maxnbest. Si le système n'a généré aucun résultat, alors le tableau application.lastresult$ aura la valeur ECMAScript "undefined".

En outre, le tableau application.lastresult$ contient lui-même les propriétés confidence, utterance, inputmode et interpretation correspondant à celles d'indice "0" dans le tableau ECMAScript.

Toutes les variables fictives décrites précédemment sont fixées immédiatement après une reconnaissance quelconque. Selon cette définition, un événement nomatch compte pour une reconnaissance et entraîne donc le remplissage du tableau application.lastresult$, quoique les valeurs qui y sont stockées dépendent de la plateforme. En outre, les valeurs existantes des variables du champ ne seront pas affectées par un événement nomatch. À l'inverse, un événement noinput ne modifiera pas le tableau application.lastresult$. Après que la valeur de la variable application.lastresult$ a été fixée, elle persiste (à moins d'être modifiée par l'application) jusqu'à ce que le navigateur entre dans l'état d'attente suivant, où sa valeur devient "undefined". Lorsqu'un document racine d'application est chargé, cette variable reçoit également la valeur "undefined. La variable application.lastresult$ et tous ses composants sont réinscriptibles et peuvent être modifiés par l'application.

L'exemple suivant montre comment se servir de application.lastresult$ dans un élément catch de niveau champ pour accéder au résultat de reconnaissance d'une grammaire de liens et pour passer à des états de dialogue différents en fonction du niveau de fiabilité :

<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="menulinkevent">
    <grammar src="/grammars/grammaire_liens.grxml" type="application/srgs+xml"/>
</link>

<form>
    <field>
        <prompt> Dites quelque chose </prompt> 
        <catch event="menulinkevent">
           <if cond="application.lastresult$.confidence &lt; 0.7">
              <goto nextitem="confirmer_dialogue_liens"/>
           <else/>
              <goto next="./menu_principal.html"/>
           </if>
        </catch>
    </field>
</form>
</vxml>

L'exemple suivant montre comment se servir d'un script pour parcourir le tableau de résultats application.lastresult$, dans lequel chaque élément est représenté par application.lastresult$[i] :

<?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>
    <field name="couleur">
        <prompt> Dites une couleur </prompt>
    <grammar type="application/srgs+xml" src="couleur.grxml" /> 
        <filled>
        <var name="compte_fiabilite" expr="0"/>
            <script>
            <![CDATA[ 
        // nombre de résultats
         var len = application.lastresult$.length;

         // parcours du tableau
         for (var i = 0; i < len; i++) {
           // vérifier si DTMF 
           if (application.lastresult$[i].confidence > .7) {
             compte_fiabilite++;
           }
         }
        ]]>
        </script>
        <if cond="compte_fiabilite > 1">
           <goto next="#verifier"/>
        </if>   
    </filled>
    </field>
</form>
</vxml>

5.2 La gestion des événements

La plateforme suscite des événements dès lors que l'utilisateur ne répond pas, qu'il ne répond pas d'une manière comprise par l'application, qu'il demande une assistance, etc. L'interpréteur suscite des événéments lorsqu'il rencontre une erreur sémantique dans un document VoiceXML ou lorsqu'il rencontre un élément throw. Les événements sont identifiés par des chaînes de caractères.

Chaque élément dans lequel un événement est susceptible de se produire admet l'ensemble des éléments de capture suivant :

• catch
• error
• help
• noinput
• nomatch

Un élément hérite, au besoin, des éléments de capture (comme par copie) de chacun de ses éléments ancêtres. Si, par exemple, un champ ne contient pas d'élément catch pour un événement nomatch mais son formulaire parent oui, alors c'est l'élément de capture de l'événement nomatch du formulaire qui sera utilisé. On peut ainsi définir un comportement commun de gestion des événements à n'importe quel niveau qui s'appliquera à tous les descendants.

La sémantique comme par copie d'héritage des éléments de capture implique que, lors de l'exécution d'un élément catch, les variables sont résolues et les événements suscités sont manipulés relativement à la portée dans laquelle l'événement original s'est produit, et non relativement à la portée contenant l'élément catch. Par exemple, prenons un élément catch défini dans la portée du document manipulant un événement initié dans un élément field dans le document. Pour un tel élément catch, les appels de variable se résolvent relativement à la portée de l'élément field, et si un événement est suscité par l'élément catch, alors il est manipulé relativement à l'élément field. De même, les appels d'adresse URI relatives dans un élément catch se résolvent par rapport au document actif et non par rapport au document dans lequel ils sont déclarés. Enfin, les propriétés se résolvent relativement à l'élément dans lequel l'événement s'est produit. Par exemple, un élément prompt, défini dans une capture de niveau document, utiliserait la valeur de la propriété la plus interne de l'élément de formulaire actif afin de résoudre son attribut timeout si aucune valeur explicite n'est définie.

5.2.1 L'élément throw

L'élément throw suscite un événement, lequel peut être l'un de ceux prédéfinis ::

<throw event="nomatch"/> 
<throw event="connection.disconnect.hangup"/>

Ou peut être défini par l'application :

<throw event="com.att.portail.machine"/>

Les attributs de l'élément throw sont :

On doit définir exactement un seul d'entre les attributs event ou eventexpr, sinon un événement error.badfetch est suscité. On peut indiquer exactement un seul d'entre les attributs message ou messageexpr, sinon un événement error.badfetch est suscité.

Sauf déclaration contraire explicite, le langage VoiceXML ne définit pas quand les événements sont suscités.

5.2.2 L'élément catch

L'élément catch associe une capture à un document, un dialogue ou un élément de formulaire (sauf les éléments block). Il contient un contenu exécutable.

<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="lancer_missiles">
  <field name="id_utilisateur" type="digits"> 
    <prompt>Quel est votre nom d'utilisateur ?</prompt> 
  </field>
  <field name="mot_de_passe"> 
    <prompt>Quel est le code d'accès ?</prompt> 
    <grammar version="1.0" root="root">
     <rule id="racine" scope="public">rutabaga</rule>
    </grammar>
   <help>C'est le nom d'un tubercule obscur.</help> 
   <catch event="nomatch noinput" count="3"> 
     <prompt>Tentative d'intrusion !</prompt> 
     <submit next="http://www.example.com/attraper_traitre.vxml" 
                namelist="id_utilisateur"/> 
   </catch> 
  </field> 
</form>
</vxml>

La portée des variables anonymes de l'élément catch inclut la variable spéciale _event, laquelle contient le nom de l'événement qui a été suscité. Par exemple, l'élément catch suivant peut manipuler deux types d'événements :

<catch event="event.foo event.bar">
  <if cond="_event=='event.foo'">
    <!-- Jouer ceci pour les événements event.foo -->
    <audio src="foo.wav"/>
  <else/>
    <!-- Jouer cela pour les événements event.bar -->
    <audio src="bar.wav"/>
  </if>
  <!-- Poursuivre par une manipulation commune à l'un ou l'autre événement -->
</catch>

La variable _event est inspectée afin de sélectionner le son à jouer en fonction de l'événement suscité. Pour un événement event.foo, ce sera le fichier foo.wav et pour un événement event.bar, le fichier bar.wav. Le reste de l'élément catch consiste en un contenu exécutable commun pour la manipulation des deux types d'événements.

La portée des variables anonymes de l'élément catch inclut également la variable spéciale _message, laquelle contient la valeur de la chaîne message issue de l'élément throw correspondant ou bien une valeur dépendant de la plateforme pour les événements prédéfinis suscitée par la plateforme. Si l'événement suscité ne donne pas de message, alors la variable _message a la valeur ECMAScript "undefined".

Lorsqu'un élément catch contient un élément throw avec le même événement, alors il risque de se produire une boucle infinie :

<catch event="help"> 
   <throw event="help"/> 
</catch>

Une platforme pourrait détecter une telle situation et susciter une erreur sémantique à la place.

Les attributs de l'élément catch sont :

5.2.3 La notation abrégée

Les éléments error, help, noinput et nomatch sont des abréviations pour les types très courants de l'élément catch.

L'élément error est un raccourci pour <catch event="error"> et capture tous les types d'erreur :

<error>
  Une erreur est survenue : veuillez rappeler ultérieurement.
  <exit/>
</error>

L'élément help est une abréviation de l'expression <catch event="help"> :

<help>Personne ne peut vous aider !</help>

L'élément noinput est une abréviation pour <catch event="noinput"> :

<noinput>Je n'ai rien entendu, veuillez réssayer.</noinput>

L'élément nomatch est un raccourci pour <catch event="nomatch"> :

<nomatch>J'ai entendu quelque chose, mais le nom de cette ville m'est inconnu.</nomatch>

Ces éléments admettent les attributs :

5.2.4 La sélection de l'élément catch

Un élément hérite, au besoin, des éléments catch (comme par copie) de chacun de ses éléments ancêtres. Par exemple, si un élément field hérite de l'élément catch du document :

<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">
<catch event="event.foo">
    <audio src="beep.wav"/>
</catch>

<form>
    <field name="couleur">
        <prompt>Veuillez indiquer une couleur primaire</prompt>
    <grammar type="application/srgs">rouge | jaune | bleu</grammar>
        <nomatch>
            <throw event="event.foo"/>
        </nomatch>
    </field>
</form>
</vxml>

Auquel cas, l'élément catch est copié implicitement dans l'élément field comme s'il était défini ainsi :

<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>
    <field>
        <prompt>Veuillez indiquer une couleur primaire</prompt>
    <grammar type="application/srgs">rouge | jaune | bleu</grammar>
        <nomatch>
            <throw event="event.foo"/>
        </nomatch>
        <catch event="event.foo">
            <audio src="beep.wav"/>
        </catch>
    </field>
</form>
</vxml>

Lorsqu'un événement est suscité, la portée dans laquelle l'événement est manipulé et ses portées englobantes sont examinées afin de trouver l'élément catch le mieux qualifié selon l'algorithme suivant :

1. Établir une liste ordonnée des captures, composée de toutes les captures dans la portée courante et toutes les portées englobantes (élément de formulaire, formulaire, document, document racine d'application, contexte d'interprétation), rangée d'abord par portée (en commençant par la portée courante) puis dans chaque portée dans l'ordre du document ;
2. Supprimer de cette liste toutes les captures dont les noms d'événement ne correspondent pas à l'événement suscité ou ceux dont l'attribut cond, après conversion en un booléen, vaut "false" ;
3. Trouver le compte correct : la valeur d'attribut count la plus élevée parmi les éléments catch encore présents dans la liste inférieure ou égale à la valeur de l'attribut count courant ;
4. Sélectionner le premier élément dans la liste ayant le compte correct.

Le nom d'un événement suscité correspond au nom d'événement de l'élément catch en cas de correspondance exacte ou de correspondance de préfixe, ou si l'élément catch ne définit pas d'attribut event (remarquez qu'on ne peut pas affecter une chaîne vide à l'attribut event ; la déclaration event="" est syntaxiquement erronnée). Une correspondance de préfixe se produit lorsque l'attribut event de l'élément catch est un préfixe atomique du nom de l'événement suscité, dont le séparateur des atomes est un caractère point, tous les points de queue sont supprimés et une chaîne restante vide représente n'importe quel atome. Par exemple :

<catch event="connection.disconnect">
   <prompt>J'ai capturé un événement connection point disconnect</prompt>
</catch>

La déclaration aura une correspondance de préfixe pour un événement connection.disconnect.transfer.

<catch event="com.exemple.kekchose">
   <prompt>J'ai capturé un événement com point exemple point kekchoset</prompt>
</catch>

Cette déclaration aura une correspondance de préfixe pour les événements com.exemple.kekchose.evenement1., com.exemple.kekchose. et com.exemple.kekchose..evenement1, mais pas pour com.exemple.kekchoses.evenement1. Finalement :

<catch event=".">
   <prompt>J'ai capturé un événement</prompt>
</catch>

Cette déclaration aura une correspondance de préfixe pour tous les événements (comme c'est le cas pour un élément catch sans attribut event).

Remarquez que l'algorithme de sélection de l'élément catch donne la priorité aux éléments catch qui apparaissent tôt dans le document sur ceux qui apparaissent tard, mais il ne donne pas la priorité aux éléments catch plus spécifiques sur ceux moins spécifiques. C'est pourquoi, on conseille, en général, de définir les éléments catch dans un ordre allant du plus spécifique au moins spécifique. Par exemple, il est judicieux de définir les éléments catch des erreurs error.foo et error, dans cet ordre, comme suit :

<catch event="error.foo"> 
  <prompt>J'ai capturé un événement error point foo</prompt>
</catch> 
<catch event="error"> 
  <prompt>J'ai capturé un événement error</prompt> 
</catch>

Si on avait défini les éléments catch dans l'ordre inverse, alors l'élément catch pour error.foo ne serait jamais exécuté.

5.2.5 Les éléments catch implicites

On attend de l'interpréteur qu'il fournisse des gestionnaires de capture par défaut implicites pour les événements noinput, help, nomatch, cancel, exit et error au cas où l'auteur ne les aurait pas indiqués.

Le comportement par défaut du système pour les gestionnaires de capture des divers événements et erreurs est résumé par les définitions suivantes, lesquelles indiquent (1) si une quelconque réponse audio doit être fournie ou non, et (2) comment l'exécution est affectée. Remarque : si une réponse audio est fournie, son contenu réel dépendra de la plateforme.

Les plateformes particulières pourront présenter des invites par défaut différentes.

5.2.6 Les types d'événement

Il existe des événements prédéfinis et des événements propres à une application ou à une plateforme. Les événements se répartissent aussi en événements réguliers (qui se produisent normalement) et en événements d'erreur (dont les occurrences sont anormales). Les conventions de nommage des erreurs permettent plusieurs niveaux de granularité.

Un navigateur conforme peut susciter un événement, qui prolonge un événement prédéfini, tant que son nom d'événement contient la chaîne du nom de l'événement prédéfini en question comme sous-chaîne initiale exacte séparée par un point. Les applications qui définissent des gestionnaires de capture pour les événements prédéfinis seront interopérables. Celles qui définissent des gestionnaires de capture pour les noms d'événement prolongés n'offrent pas toutes les garanties d'interopérabilité. Par exemple, si au cours du chargement d'un fichier de grammaire une erreur est détectée, la plateforme doit susciter un événement error.badfetch. Susciter un événement error.badfetch.grammar.syntax est une implémentation acceptable.

Les composants des noms d'événement mis en exergue doivent être remplacés par l'information adéquate ; par exemple, dans error.unsupported.élément, on remplace élément par le nom de l'élément VoiceXML qui n'est pas pris en charge, comme error.unsupported.transfer. Tous les autres composants du nom d'événement sont fixes.

On peut fournir d'autres renseignements à propos de l'événement dans la variable _message (voir le chapitre 5.2.2).

Les événements prédéfinis sont :

cancel

L'utilisateur a demandé l'annulation de la lecture de l'invite courante.

connection.disconnect.hangup

L'utilisateur a raccroché.

connection.disconnect.transfer

L'utilisateur a été transféré inconditionnellement sur une autre ligne et il ne reviendra pas.

exit

L'utilisateur a demandé à quitter.

help

L'utilisateur a demandé une assistance.

noinput

L'utilisateur n'a pas répondu dans le délai imparti.

nomatch

L'utilisateur a entré quelque chose qui n'a pas été reconnue.

maxspeechtimeout

L'entrée d'utilisateur est trop longue et dépasse la valeur de la propriété maxspeechtimeout.

Outre les erreurs de transfert (voir le chapitre 2.3.7.3), les erreurs prédéfinies sont :

error.badfetch

Le contexte d'interprétation suscite cet événement quand le chargement d'un document a échoué et quand le contexte d'interprétation est arrivé au point dans l'interprétation du document où le résultat du chargement est nécessaire. Les échecs de chargement sont dûs aux appels dans un système d'adressage non géré, aux adresse URI malformées, aux abandons des clients, aux erreurs de connexion, aux dépassements de délai, aux violations de sécurité, aux types de ressource non gérés, aux désaccords entre les types de ressource, aux erreurs d'analyse du document et aux diverses erreurs représentées par des codes d'erreur propres au système d'adressage.

Si le contexte d'interprétation a effectué le préchargement spéculatif d'un document et que ce document se révèle inutile, il ne sera pas suscité d'événement error.badfetch. De même, si le chargement d'un élément audio échoue et qu'il existe un élément audio imbriqué de remplacement dont le chargement réussit, ou s'il existe un texte de remplacement imbriqué, alors il ne sera pas suscité d'événement error.badfetch.

Lorsqu'un contexte d'interprétation effectue une transition vers un nouveau document, il suscite un événement error.badfetch en cas d'erreur jusqu'à ce que l'interpréteur puisse exécuter le nouveau document, une fois encore seulement à l'instant où le nouveau document est réellement demandé et pas avant. Le fait de considérer l'initialisation des variables comme faisant partie ou non de l'exécution du nouveau document dépendra de la plateforme.

error.badfetch.http.code_réponse
error.badfetch.protocole.code_réponse

En cas d'échec de chargement, le contexte d'interprétation doit employer un type d'événement précis indiquant le code de réponse HTTP ou propre à un autre protocole particulier qui a été reçu. La valeur du code de réponse HTTP est définie dans le document [RFC2616]. Cette annonce, par exemple, permet aux applications de traiter différemment un document manquant et un document interdit. La valeur du code de réponse d'autres protocoles (tels que HTTPS, RTSP, et ainsi de suite) dépendra du protocole en question.

error.semantic

Une erreur d'exécution a été détectée dans le document VoiceXML, par exemple, une erreur sur les bornes d'une sous-chaîne ou l'appel d'une variable non définie.

error.noauthorization

Une événement suscité lorsque l'application essaye d'effectuer une opération non autorisée par la plateforme. Comme examples : composer un numéro de téléphone invalide ou un numéro que l'utilisateur n'est pas autorisé à appeler, ou essayer d'accéder à une base de données protégée au travers d'un élément object propre à la plateforme, ou un accès inapproprié aux grammaires intégrées, etc.

error.noresource

Une erreur d'exécution est survenue parce qu'une ressource nécessaire de la plateforme n'était pas disponible pour l'exécution.

error.unsupported.builtin

La plateforme ne gère pas un type ou une grammaire obligatoires intégrés.

error.unsupported.format

La ressource demandée est dans un format non géré par la plateforme, par exemple, un format de grammaire ou un type de média non gérés.

error.unsupported.language

La plateforme ne gère pas la langue de la voix synthétisée ou celle de la reconnaissance vocale.

error.unsupported.objectname

La plateforme ne gère pas un objet particulier propre à une plateforme. Remarquez que objectname est une chaîne fixe, qui ne se remplace pas par le nom de l'objet non géré.

error.unsupported.élément

La plateforme ne gère pas l'élément en question, où élément représente un élément VoiceXML défini dans la présente spécification. Par exemple, si la plateforme ne prend pas en charge l'élément transfer, elle doit susciter un événement error.unsupported.transfer. Ce mécanisme permet à l'auteur une gestion des événements en fonction des différentes capacités des plateformes.

Les erreurs rencontrées au cours du chargement d'un document, y compris les erreurs de transport (le document introuvable du code de statut 404 du protocole HTTP, et ainsi de suite) et les erreurs syntaxiques (absence d'un élément vxml, etc.), aboutissent au déclenchement d'un événement error.badfetch dans le document appelant. Les erreurs qui se produisent après le chargement et avant l'entrée dans la phase d'initialisation de l'algorithme FIA sont prises en charge de manière spécifique à la plateforme. Celles qui se produisent après la phase d'initialisation, comme les erreurs sémantiques, se déclenchent dans le nouveau document. La prise en charge des erreurs rencontrées au cours du chargement du premier document d'une session est propre à la plateforme.

Les types d'événement propres aux applications et aux plateformes devraient utiliser la convention de nom de domaine Internet inversée pour éviter les conflits de nommage. Par exemple :

error.com.example.plateformevocale.nonautorise

L'utilisateur n'est pas autorisé aux accès externes sur cette plateforme.

org.example.voice.unecertaineapplication.tropdesilences

L'utilisateur est trop silencieux.

Les captures peuvent concerner des événements particuliers (cancel) ou tous ceux partageant un préfixe (error.unsupported).

5.3 Le contenu exécutable

Un contenu exécutable se rapporte à un bloc de logique procédurale. On trouve des logiques de ce type dans :

• L'élément de formulaire block ;
• L'élément d'action filled dans les formulaires et les éléments d'entrée ;
• Les gestionnaires d'événements (catch, help, etc.).

Les éléments exécutables sont traités dans l'ordre du document dans leur bloc de logique procédurale. Si un élément exécutable génère une erreur, alors elle l'est immédiatement. Les éléments exécutables suivants dans ce bloc de logique procédurale ne sont pas exécutés.

Ce chapitre couvre les éléments qui peuvent apparaître dans un contenu exécutable.

5.3.1 L'élément var

Cet élément déclare une variable. Il peut apparaître dans un contenu exécutable ou comme enfant d'un élément form ou d'un élément vxml. Exemples :

<var name="telephone" expr="'+689 123456'"/> 
<var name="y" expr="document.z+1"/>

S'il apparaît dans un contenu exécutable, alors l'élément déclare une variable dans la portée anonyme associée à l'élément block, ou l'élément filled, ou l'élément catch englobants. Cette déclaration n'intervient qu'au moment où l'élément var est exécuté. Si la variable est déjà déclarée dans cette portée, alors les déclarations suivantes agissent comme des affectations, comme dans le langage ECMAScript.

Si l'élément var est un enfant d'un élément form, alors il déclare une variable dans la portée du dialogue de l'élément form. Cette déclaration intervient pendant la phase d'initialisation du formulaire, comme décrit dans le chapitre 2.1.6.1. L'élément var n'est pas un élément de formulaire, c'est la raison pour laquelle il n'est pas visité dans la boucle principale de l'algorithme FIA.

Si l'élément var est un enfant d'un élément vxml, alors il déclare une variable dans la portée du document ; si, en outre, c'est un enfant d'un élément vxml dans un document racine, alors il déclare la variable dans la portée de l'application. Cette déclaration intervient lorsque le document est initialisé ; les initialisations ont lieu dans l'ordre du document.

Les attributs de l'élément var sont :

5.3.2 L'élément assign

L'élément assign affecte une valeur à une variable :

<assign name="parfum" expr="'chocolat'"/> 
<assign name="document.cout" expr="document.cout+14"/>

Il est interdit d'affecter une valeur à une variable qui n'aura pas été déclarée explicitement par un élément var ou par une déclaration var dans un élément script. Une tentative d'affectation d'une variable non définie suscitera un événement error.semantic.

Remarquez que, lorsqu'un objet ECMASCript, disons obj, a été correctement initialisé, alors ses propriétés, par exemple obj.prop1, peuvent être assignées sans déclaration explicite (en fait, une tentative de déclaration de la propriété d'un objet ECMAScript, telle que obj.prop1, déclenchera un événement error.semantic).

Les attributs de l'élément assign sont :

5.3.3 L'élément clear

L'élément clear réinitialise une ou plusieurs variables, y compris celles des éléments de formulaire. Quel que soit le nom de variable défini, la variable se résoud relativement à la porté courante conformément aux indications du chapitre 5.1.3 (pour lever toute ambiguïté, on peut préfixer chaque nom de variable dans l'attribut namelist avec un nom de portée). Une fois la variable déclarée identifiée, on lui affecte la valeur ECMAScript "undefined". En outre, si le nom de la variable correspond à celui d'un élément de formulaire, alors le compteur d'invites et les compteurs d'événements de cet élément de formulaire sont réinitialisés.

Par exemple :

<clear namelist="ville departement code_postal"/>

L'attribut de l'élément clear est :

5.3.4 Les élément if, elseif et else

L'élément if sert dans la logique conditionnelle. Il s'accompagne des éléments optionnels else et elseif.

<if cond="total > 1000"> 
  <prompt>Cette dépense est trop importante.</prompt> 
  <throw event="com.ciexyz.compte.tropdepense"/> 
</if> 

<if cond="montant &lt; 29.95"> 
  <assign name="x" expr="montant"/> 
<else/> 
  <assign name="x" expr="29.95"/> 
</if> 

<if cond="parfum == 'vanille'"> 
  <assign name="code_parfum" expr="'v'"/> 
<elseif cond="parfum == 'chocolat'"/> 
  <assign name="code_parfum" expr="'c'"/> 
<elseif cond="parfum == 'fraise'"/> 
  <assign name="code_parfum" expr="'f'"/> 
<else/> 
  <assign name="code_parfum" expr="'?'"/> 
</if>

5.3.5 Les éléments prompt

Les invites peuvent apparaître dans un contenu exécutable, dans leur généralité complète, mis à part l'attribut count de l'élément prompt qui n'a aucune signification. On peut notamment utiliser l'attribut cond dans un contenu exécutable. L'invite peut se trouver englobée dans des balises <prompt> et </prompt>, ou être représentée par des caractères de type PCDATA. Partout où l'élément prompt est susceptible d'apparaître, une chaîne de type PCDATA, par exemple xyz, sera interprétée comme si elle était apparue sous la forme <prompt>xyz</prompt>.

<nomatch count="1"> 
  Pour ouvrir la porte de la nacelle, prononcez clairement votre phrase secrète.
</nomatch> 

<nomatch count="2"> 
  <prompt>
    C'est votre <emphasis>dernière</emphasis> chance.
  </prompt> 
</nomatch> 

<nomatch count="3"> 
  Accès refusé. 
  <exit/> 
</nomatch>

5.3.6 L'élément reprompt

L'algorithme FIA attend d'un élément catch qu'il place en file d'attente les invites appropriées dans le cadre de la gestion d'un événement. C'est pourquoi il n'effectue généralement pas la sélection et la mise en file d'attente normales des invites dans l'itération qui suit l'exécution d'un élément de capture. Néanmoins, l'algorithme FIA effectuera une sélection et un mise en file d'attente normales des invites après l'exécution d'un élément de capture (catch, error, help, noinput, nomatch) dans deux cas :

• lorsque l'élément de capture se termine par l'exécution d'un élément goto ou submit menant à un autre dialogue, ou lorsqu'il se termine par un élément return revenant d'un sous-dialogue ; auquel cas le nouveau dialogue doit avoir l'assurance que son invite initiale reste intacte et ne puisse pas être supprimée ou remplacée par un dialogue appelant, ou ;
• lorsqu'un élément reprompt est exécuté dans l'élément de capture pour demander que les invites suivantes soient jouées.

Dans ces deux cas, après que l'algorithme FIA a sélectionné l'élément de formulaire suivant à visiter, il opère le traitement normal des invites, à savoir la sélection et la mise en file d'attente des invites de l'élément de formulaire et l'incrémentation du compteur d'invites de l'élément de formulaire en question.

Par exemple, cette capture noinput attend que l'invite suivante de élément de formulaire soit sélectionnée puis jouée :

<field name="vouloir_glace"> 
  <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
  <prompt>Voulez-vous une glace pour le dessert ?</prompt> 
  <prompt count="2"> 
    Si vous voulez une glace, dites oui. 
    Si vous ne voulez pas de glace, dites non. 
  </prompt> 
  <noinput> 
    Je n'ai rien entendu. 
    <!-- Entraîne la sélection et la lecture de l'invite suivante. --> 
    <reprompt/>
  </noinput> 
</field>

Un utilisateur silencieux entendrait :

O : Voulez-vous une glace pour le dessert ?

H : (silence)

O : Je n'ai rien entendu.

O : Si vous voulez une glace, dites oui. Si vous ne voulez pas de glace, dites non.

H : (silence)

O : Je n'ai rien entendu.

O : Si vous voulez une glace, dites oui. Si vous ne voulez pas de glace, dites non.

H : Non

S'il n'y avait pas d'élément reprompt, l'utilisateur aurait entendu à la place :

O : Voulez-vous une glace pour le dessert ?

H : (silence)

O : Je n'ai rien entendu.

H : (silence)

O : Je n'ai rien entendu.

H : Non

Remarquez que le fait de sauter la phase de sélection des invites, comme décrit précédemment, a pour conséquence de ne pas incrémenter le compteur d'invites de l'élément de formulaire sélectionné par l'algorithme FIA, après l'exécution d'un élément de capture (celui-ci n'exécutant pas d'élément reprompt ni ne quittant le dialogue via un élément goto, submit ou bien return).

Remarquez également que la phase de sélection des invites suivant l'exécution d'un élément de capture (celui-ci n'exécutant pas d'élément reprompt ni ne quittant le dialogue via un élément goto, submit ou bien return) est sautée, même si l'élément de formulaire sélectionné par l'algorithme FIA est différent de l'élément de formulaire précédent.

L'élément reprompt n'a aucun effet en dehors d'un élément de capture.

5.3.7 L'élément goto

L'élément goto sert à :

• effectuer une transition vers un autre élément de formulaire dans le formulaire courant ;

• effectuer une transition vers un autre dialogue dans le document courant, ou ;

• effectuer une transition vers un autre document.

Pour opérer une transition vers un autre élément de formulaire, utilisez l'attribut nextitem, ou l'attribut expritem si le nom de l'élément de formulaire est calculé au moyen d'une expression ECMAScript :

<goto nextitem="confirmer_ssn"/> 
<goto expritem="(type==12)? 'confirmer_ssn' : 'rejeter'"/>

Pour aller à un autre dialogue dans le même document, utilisez l'attribut next (ou bien expr) avec seulement un fragment d'adresse URI :

<goto next="#autre_dialogue"/> 
<goto expr="'#' + 'autre_dialogue'"/>

Pour opérer une transition vers un autre document, utilisez l'attribut next (ou bien expr) avec une adresse URI :

<goto next="http://vol.example.com/reserver_place"/> 
<goto next="./repas_special#menu_vegetarien"/>

L'adresse URI peut être absolue ou relative au document courant. On peut indiquer le dialogue de départ dans le document suivant au moyen d'un fragment correspondant à la valeur de l'attribut id d'un dialogue. Si on n'indique pas de fragment, alors c'est le premieur dialogue de ce document qui sera choisi.

Remarquez que le passage à un autre dialogue dans le document courant entraîne la perte des variables de l'ancien dialogue, même quand la transition s'opère sur l'élément en question. De la même manière, le passage à un autre document via une adresse URI absolue ou relative causera l'abandon des anciennes variables de niveau document, même si le nouveau document est celui initiant la transition. Par contre, les variables des documents persistent dans la transition vers un appel d'adresse URI vide avec un identificateur de fragment. Par exemple, les déclarations suivantes amènent un comportement différent dans un document dont l'adresse URI est http://unecie.example.com/index.vxml :

<goto next="#foo"/>

<goto next="http://unecie.example.com/index.vxml#foo"/>

Selon le document [RFC2396], l'identificateur de fragment (la partie après le caractère dièse #) ne faisant pas partie de l'adresse URI, la transition opérée par un appel d'adresse URI vide plus un identificateur de fragment ne devrait jamais aboutir à un nouveau chargement de document. Par conséquent, le fragment #foo dans la première déclaration correspond à un appel d'adresse URI vide avec un identificateur de fragment, et les variables du document sont retenues. Dans la seconde déclaration, le fragment #foo fait partie d'une adresse URI absolue et, à ce titre, les variables du document sont perdues. Si on veut que des données persistent entre plusieurs documents, il faut stocker ces données dans la portée de l'application.

Le dialogue vers lequel opérer une transition est défini par l'appel d'adresse URI de l'attribut next ou bien expr de l'élément goto (voir le document [RFC2396]). Si cet appel d'adresse URI contient une adresse absolue ou relative, incluant éventuellement une chaîne de requête, alors cette adresse URI fait l'objet d'un chargement et le dialogue se trouvera dans le document résultant.

Si l'appel d'adresse URI contient seulement un fragment (c'est-à-dire que l'adresse URI n'est ni absolue ni relative), alors aucun chargement n'a lieu : le dialogue se trouve dans le document courant.

Le cas échéant, le fragment de l'appel d'adresse nomme le dialogue vers lequel opérer la transition. En l'absence d'un fragment, le premier dialogue lexical dans le document sera choisi.

Si l'élément de formulaire, le dialogue ou le document vers lesquels opérer la transition ne sont pas valides (c'est-à-dire que l'élément de formulaire, le dialogue ou le document n'existent pas), alors il sera suscité un événement error.badfetch. Remarquez que, en ce qui concerne les erreurs survenant au cours d'une transition vers un dialogue ou un document, c'est la plateforme qui gère la portée dans laquelles elles sont gérées. Pour les erreurs qui surviennent au cours d'une transition vers un élément de formulaire, l'événement est géré dans la portée du dialogue.

Les attributs de l'élément goto sont :

On doit définir exactement un seul d'entre les attributs next, expr, nextitem ou expritem, sinon un événement error.badfetch est suscité.

5.3.8 L'élément submit

L'élément submit sert à soumettre des informations au serveur Web d'origine puis à opérer une transition vers le document renvoyé en réponse. À la différence de l'élément goto, il permet de soumettre une liste de variables au serveur de documents via une requête HTTP GET ou POST. Par exemple, pour soumettre un ensemble d'éléments de formulaire au serveur, on pourrait avoir :

<submit next="journal_requetes" method="post"
 namelist="nom rang numero_serie" 
 fetchtimeout="100s" fetchaudio="audio/brahms2.wav"/>

Le dialogue vers lequel effectuer la transition est indiqué par l'appel d'adresse URI dans l'attribut next ou attribut expr de l'élément submit (voir le document [RFC2396], chapitre 4.2). L'adresse URI est toujours extraite, même quand elle ne contient qu'un fragment. Dans le cas d'un fragment, l'adresse URI demandée est la l'adresse URI de base du document courant. Par conséquent, les deux éléments suivants produisent des effets très différents :

<goto next="#obtenir_pin"/>

<submit next="#obtenir_pin"/>

Remarquez que, bien que l'adresse URI soit toujours extraite et que la transisition vers le document résultant ait lieu, certaines requêtes par l'élément submit peuvent être satisfaites par des caches intermédiaires. Cela peut se produire, par exemple, si le serveur Web d'origine fournit une date d'expiration explicite avec la réponse.

Si le dialogue ou le document de la transition ne sont pas valides (c'est-à-dire que le dialogue ou le document n'existent pas), un événement error.badfetch devra être suscité. Remarquez que, pour les erreurs qui surviennent au cours de la transition vers un dialogue ou un document, la portée dans laquelle les erreurs seront gérées dépendra de la plateforme.

Les attributs de l'élément submit sont :

On doit définir exactement un seul d'entre les attributs next ou expr, sinon un événement error.badfetch est suscité.

Lors de la soumission d'une variable ECMAScript au serveur, sa valeur est préalablement convertie en une chaîne. Si cette variable est un objet ECMAScript, le mécanisme selon lequel elle est soumise n'est pas défini pour l'instant et reste à définir dans une version future. Au lieu de soumettre directement les objets ECMAScript, le développeur de l'application peut soumettre explicitement les propriétés de l'objet concerné, par exemple, comme dans date.month date.year.

Si un élément submit contient une variable appelant un son enregistré et que l'attribut enctype n'a pas la valeur "multipart/form-data", alors le comportement n'est pas défini. Également, essayer d'appliquer un codage d'adresse URL sur une grande quantité de données ne constitue probablement pas une bonne idée.

5.3.9 L'élément exit

L'élément exit repasse le contrôle au contexte d'interprétation qui détermine quoi faire ensuite.

<exit/>

Cet élément se distingue de l'élément return en cela qu'il termine tous les documents chargés, tandis que l'élément return revient de l'invocation d'un élément subdialog. Si cet élément subdialog a causé l'invocation d'un nouveau document (ou d'une nouvelle application), alors l'élément return terminera ce document, mais l'exécution reprendra après l'élément subdialog.

Remarquez que, une fois le contrôle repassé au contexte d'orientation par l'élément exit, le contexte d'interprétation est libre d'agir à sa guise : il peut, par exemple, jouer un menu de niveau supérieur pour l'utilisateur, abandonner l'appel en cours ou transférer l'utilisateur vers un opérateur.

Les attributs de l'élément exit comprennent :

On doit définir exactement un seul d'entre les attributs expr ou namelist, sinon un événement error.badfetch est suscité.

L'élément exit ne suscite pas un événement exit.

5.3.10 L'élément return

L'élément return termine l'exécution d'un sous-dialogue, et il repasse le contrôle, en renvoyant des données, au dialogue appelant.

Les attributs de l'élément return sont :

On doit définir exactement un seul d'entre les attributs event, eventexpr ou namelist, sinon un événement error.badfetch est suscité. On doit définir exactement un seul d'entre les attributs message ou messageexpr, sinon un événement error.badfetch est suscité.

Au retour d'un sous-dialogue, un événement pourra être suscité au point d'invocation ou des données seront renvoyées sous forme d'un objet ECMAScript dont les propriétés correspondront aux variables indiquées dans l'attribut namelist. Un élément return qui apparaîtrait en dehors de l'exécution d'un sous-dialogue suscitera un événement error.semantic.

L'exemple ci-dessous montre un événement propagé depuis un sous-dialogue vers le dialogue appelant quand le sous-dialogue n'a pas réussi à obtenir un résultat reconnaissable. Il montre également des données renvoyées dans les conditions normales :

<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> 
  <subdialog name="resultat" src="#obtenir_nss"> 
    <nomatch> 
      <!-- un événement nomatch renvoyé par le sous-dialogue
          indique l'échec de la correspondance avec un
          numéro de sécurité sociale. --> 
      <goto next="http://monservice.example.com/problemes_nss.vxml"/> 
    </nomatch> 

    <filled> 
      <submit namelist="resultat.nss" 
       next="http://monservice.example.com/cgi-bin/traitement"/> 
    </filled> 
  </subdialog> 
</form>
<form id="obtenir_nss"> 
  <field name="nss"> 
      <grammar src="http://grammarlib/nss.grxml" 
        type="application/srgs+xml"/>
      <prompt> Veuillez indiquer un numéro de sécurité sociale.</prompt> 
      <nomatch count="3">
        <return event="nomatch"/> 
      </nomatch> 
      <filled> 
        <return namelist="nss"/> 
      </filled> 
  </field> 
</form>
</vxml>

Le gestionnaire d'événement du sous-dialogue pour l'élément nomatch se déclenche à la troisième tentative infructueuse ; le gestionnaire provoque le retour du sous-dialogue en incluant l'événement nomatch à susciter dans le contexte du dialogue appelant. Auquel cas, le dialogue appelant exécutera son gestionnaire nomatch, au lieu de l'élément filled, l'action résultante consistant à exécuter un élément goto. En conditions normales, l'élément filled du sous-dialogue est exécuté après qu'un numéro de sécurité sociale reconnu a été obtenu, puis cette valeur est renvoyée au dialogue appelant qui en disposera dans la variable resultat.nss.

5.3.11 L'élément disconnect

L'élément disconnect entraîne la déconnexion du contexte d'interprétation et de l'utilisateur. En conséquence, le contexte d'interprétation suscitera un événement connection.disconnect.hangup et entrera dans l'état de traitement final (comme décrit dans le chapitre 1.5.4). Le traitement de l'élément disconnect purgera également la file d'attente des invites (comme décrit dans le chapitre 4.1.8).

5.3.12 L'élément script

L'élément script qui permet de définir un bloc de code en langage de script côté client est analogue à l'élément <SCRIPT> de [HTML]. Par exemple, ce document contient un script qui calcule une factorielle :

<?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"> 
    <script> <![CDATA[ 
       function factorielle(n) 
       {
         return (n <= 1)? 1 : n * factorielle(n-1);
       } 
    ]]> </script> 

  <form id="formulaire"> 
    <field name="fact"> 
      <grammar type="application/srgs+xml" src="/grammars/number.grxml"/>
      <prompt>
        Dites un nombre et je vous donnerai sa factorielle.
      </prompt> 
      <filled> 
        <prompt> 
          La factorielle de <value expr="fact"/> est
          <value expr="factorielle(fact)"/> 
        </prompt> 
      </filled> 
    </field> 
  </form> 
</vxml>

L'élément script peut apparaître dans les éléments vxml et form, ou dans un contenu exécutable (dans les éléments filled, if, block, catch ou les formes abrégées de catch. Les scripts dans les éléments vxml sont évalués juste après que le document a été chargé, en même temps que les éléments var, dans l'ordre du document. Les scripts dans les éléments form sont évalués dans l'ordre du document, en même temps que les éléments var et les variables d'élément de formulaire, à chaque fois que l'exécution entre sur le terrain de l'élément form. Un élément script dans un contenu exécutable s'exécute, comme tous les autres éléments exécutables, au fur et à mesure de leur apparition.

Les attributs de l'élément script sont :

On doit définir soit un attribut src, soit un script direct (mais pas les deux), sinon il sera suscité un événement error.badfetch

L'élément script de VoiceXML (contrairement à l'élément <SCRIPT> de [HTML]) n'admet pas d'attribut de type ; le langage de script ECMAScript est obligatoire pour VoiceXML.

Chaque élément script est exécuté dans la portée de l'élément qui le contient ; c'est-à-dire qu'il n'a pas de portée propre. Cela signifie, par exemple, que les variables définies au moyen de l'élément var dans l'élément script sont déclarées dans la portée de l'élément contenant l'élément script. (Dans la terminologie ECMAScript, la variable d'object devient la portée courante de l'élément contenant l'élément script).

Voici un service d'horloge parlante avec un élément block contenant un élément script qui initialise les variables temporelles dans la portée de dialogue d'un formulaire :

<?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> 
    <var name="heures"/> 
    <var name="minutes"/> 
    <var name="secondes"/> 
    <block> 
      <script> 
        var d = new Date(); 
        heures = d.getHours(); 
        minutes = d.getMinutes(); 
        secondes = d.getSeconds(); 
      </script> 
    </block> 
    <field name="entendre_maj"> 
      <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
      <prompt> 
        Il est <value expr="heures"/> heures, 
        <value expr="minutes"/> minutes et 
        <value expr="secondes"/> secondes. 
      </prompt> 
      <prompt>Voulez-vous entendre l'heure mise à jour ?</prompt> 
      <filled> 
        <if cond="entendre_maj"> 
          <clear/> 
        </if> 
      </filled> 
    </field> 
  </form> 
</vxml>

Le contenu d'un élément script est évalué dans la même portée qu'un élément var (voir le chapitre 5.1.2 et le chapitre 5.3.1).

La chaîne des portées ECMAScript (voir le chapitre 10.1.4 dans [ECMASCRIPT]) est fixée de telle sorte que les variables déclarées soit au moyen d'un élément var, soit dans un élément script s'inscrivent dans la portée associée à l'élément dans lequel les éléments var ou script apparaissent. Par exemple, la variable déclarée dans un élément script contenu dans un élément form aura une portée de dialogue et pourra être appelée en tant que variable de portée de dialogue, comme suit :

<?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> 
    <script> 
      var illico = new Date(); <!-- c'est une portée de dialogue-->
    </script>
    <var name="secondes" expr="illico.getSeconds()"/> <!-- c'est une portée de dialogue -->
    <block> 
      <var name="illico" expr="new Date()"/> <!-- c'est une portée anonyme -->
      <script> 
        var current = illico.getSeconds();    <!-- "illico" dans la portée anonyme -->
        var approx = dialog.illico.getSeconds(); <!-- "illico" dans la portée du dialogue -->
      </script> 
    </block> 
  </form> 
</vxml>

On doit déclarer toutes les variables avant de pouvoir les appeler par des scripts ECMAScript, ou par des éléments VoiceXML, comme décrit dans le chapitre 5.1.1.

5.3.13 L'élément log

L'élément log permet à une application de générer un message de journalisation ou de débogage dont le développeur peut se servir pour aider au développement de l'application ou pour l'analyse post-exécution des performances de l'application.

L'élément log peut contenir une combinaison quelconque de texte (de type CDATA) et d'élément value. Le message généré est constitué par la concaténation du texte et de la forme textuelle de la valeur de l'attribut expr des éléments value.

La façon dont le message est affiché ou journalisé dépend de la plateforme. L'usage de l'attribut label dépend de la plateforme. Les plateformes ne sont pas obligées de préserver les blancs.

Les expressions ECMAScript des éléments log doivent être évaluées dans l'ordre du document. L'utilisation d'un élément log ne devrait avoir aucun effet secondaire sur l'interprétation.

<log>La carte avait le numéro <value expr="num_carte"/></log>

Les attributs de l'élément log sont :

6. L'environnement et les ressources

6.1 La mise en place des ressources

6.1.1 Le chargement

Un contexte d'interprétation VoiceXML a besoin de charger des documents VoiceXML et d'autres ressources, tels que des fichiers sons, des grammaires, des scripts et des objets. Chaque chargement du contenu associé à une adresse URI est régi par les attributs suivants :

Lorsqu'un contenu est chargé à partir d'une adresse URI, l'attribut fetchtimeout détermine combien de temps attendre le contenu (en commençant à partir du moment où la ressource sera devenue nécessaire) et l'attribut fetchhint détermine à quel moment le contenu sera chargé. La politique de mise en cache d'un contexte d'interprétation VoiceXML exploite les attributs maxage et maxstale de la manière décrite ci-dessous.

L'attribut fetchhint, en combinaison avec les diverses propriétés fetchhint, donne simplement au contexte d'interprétation un indice sur le moment où il peut lancer le chargement d'une ressource. Indiquer au contexte d'interprétation qu'il peut précharger une ressource n'impose pas son chargement ; c'est seulement suggérer que cette ressource peut être préchargée. Toutefois, le contexte d'interprétation est toujours obligé d'honorer la valeur "safe" de l'attribut fetchhint.

Lors d'une transition d'un dialogue à un autre, que ce soit au travers d'un élément subdialog, goto, submit, link ou bien choice, d'autres règles viennent affecter le comportement de l'interpréteur. Si l'appel d'adresse URI nomme un document (par exemple, document#dialogue), ou si des données de requête sont fournies (au travers de la méthode POST ou GET), alors un nouveau document sera obtenu (qu'il soit issu d'un cache local, d'un cache intermédiaire ou d'un serveur Web d'origine). Lorsque le document est reçu, il entre dans sa phase d'initialisation (c'est-à-dire, obtenir et initialiser un nouveau document racine d'application au besoin, initialiser les variables de document et exécuter les scripts de document). Le dialogue demandé (ou le premier venu si aucun n'est indiqué) est alors initialisé et l'exécution du dialogue commence.

En général, si un appel d'adresse URI ne contient qu'un fragment (par exemple, #mon_dialogue), alors aucun document n'est chargé et aucune initialisation de ce document n'a lieu. Au contraire, l'exécution d'un élément submit se conclut toujours par un chargement, et ce sera aussi le cas si un attribut namelist accompagne le fragment en question.

Une autre exception, c'est quand un appel d'adresse URI dans un document terminal référence le document racine d'application. Auquel cas, la transition vers le document racine intervient sans chargement ni initialisation, même si l'appel d'adresse URI se compose d'une adresse URI absolue ou relative (voir le chapitre 1.5.2 et le document [RFC2396]). Par contre, si l'appel d'adresse URI vers le document racine contient une chaîne de requête, ou un attribut namelist, alors le document racine sera chargé.

Les éléments susceptibles de charger des documents VoiceXML gèrent également cet autre attribut :

L'attribut fetchaudio trouve une utilité dans l'amélioration de l'expérience d'utilisateur, lorsque des délais perceptibles sont susceptibles de se manifester pour le chargement du document suivant. Il peut servir à jouer une musique de fond ou une succession d'annonces. Une fois le document chargé, la lecture du fichier son s'interrompt s'il jouait encore. Si une erreur survient au cours du chargement du son d'attente à partir de son adresse URI, aucun événement error.badfetch ne sera suscité et aucun son ne sera joué pendant le chargement.

6.1.2 La mise en cache

Le contexte d'interprétation VoiceXML, tout comme les navigateurs visuels [HTML], peut utiliser une mise en cache pour améliorer les performances de chargement des documents et des autres ressources ; les enregistrements sonores (qui peuvent être très volumineux) sont aussi fréquents dans les documents VoiceXML que les images le sont dans les documents HTML. Dans un navigateur visuel, il est courant d'inclure des commandes d'utilisateur final qui permettent de mettre à jour ou de rafraîchir un contenu perçu comme étant expiré. Ce n'est pas le cas dans le contexte d'interprétation VoiceXML en raison de l'absence de commandes d'utilisateur final équivalentes. C'est pourquoi le rafraîchissement du cache reste à la discrétion du document au travers de l'emploi approprié des attributs maxage et maxstale.

La politique de mise en cache suivie par le contexte d'interprétation VoiceXML doit adhérer aux règles d'exactitude de cache du protocole HTTP 1.1 ([RFC2616]). Les en-têtes Expires et Cache-Control doivent notamment être respectées. L'algorithme suivant résume ces règles et représente le comportement du contexte d'interprétation dans la requête d'une ressource :

• Si la ressource n'est pas présente en cache, la charger du serveur en utilisant la méthode get,
• Si la ressource est en cache :
  • Si l'attribut maxage a une valeur :
    • Si l'âge de la ressource en cache est <= maxage
      • Si la ressource est expirée
        • Vérifier l'attribut maxstale.
      • Sinon, utiliser la copie en cache.
    • Sinon, la charger du serveur au moyen de la méthode get.
  • Sinon,
    • Si la ressource est expirée :
      • Vérifier l'attribut maxstale.
    • Sinon, utiliser la copie en cache.

La vérification de l'attribut maxstale est la suivante :

• Si l'attribut maxstale est fourni,
  • Si la copie en cache a dépassé sa date d'expiration de pas plus de la valeur en secondes de l'attribut maxstale, alors utiliser la copie en cache.
  • Sinon, la charger du serveur au moyen de la méthode get.
• Sinon, la charger du serveur au moyen de la méthode get.

Remarque : Effectuer un rechercher si modifié sur un document toujours présent dans le cache, lorsque la politique requiert un chargement à partir du serveur, représente une optimisation.

Les propriétés maxage et maxstale peuvent ne pas avoir la moindre valeur par défault. Si la valeur n'est pas donnée par l'auteur du document et que la plateforme ne fournit pas de valeur par défaut, alors la valeur est "undefined" et la clause Sinon de l'algorithme s'appliquera. Toutes les autres propriétés doivent fournir une valeur par défaut (qu'elle soit donnée par la spécification ou bien par la plateforme).

Alors que les attributs maxage et maxstale sont issus du protocole HTTP 1.1 et directement gérés par lui, certaines ressources peuvent être appelées par des adresses URI qui empruntent des protocoles autres que HTTP. Si le protocole ne gère pas la notion d'âge d'une ressource, le contexte d'interprétation calculera l'âge de la ressource à partir du moment où elle aura été reçue. Si le protocole ne gère pas la notion d'expiration d'une ressource, le contexte d'interprétation considérera que la ressource aura expiré immédiatement à réception.

6.1.2.1 Le contrôle de la politique de mise en cache

Le langage VoiceXML permet à l'auteur de surcharger le comportement de mise en cache par défaut pour chaque usage de chacune des ressources (sauf un éventuel document appelé par l'attribut application de l'élément vxml, car il n'existe pas de mécanisme de balisage permettant de contrôler la politique de mise en cache d'un document racine d'application).

Chaque élément relié à une ressource peut spécifier des attributs maxage et maxstale. Le fait de fixer une valeur non nulle à l'attribut maxage peut servir à obtenir une nouvelle copie d'une ressource qui n'aura pas encore expiré dans le cache. On peut demander inconditionnellement une nouvelle copie en fixant la valeur de l'attribut maxage à "0".

L'utilisation de l'attribut maxstale permet à l'auteur de déclarer que l'on peut se servir de la copie expirée d'une ressource, le délai d'expiration n'étant pas trop dépassé (selon les règles du protoxole HTTP 1.1). Cela peut procurer une amélioration des performances en éliminant un chargement qui, sinon, aurait été nécessaire pour obtenir une nouvelle copie. Cette fonctionnalité est particulièrement utile pour les auteurs ne disposant pas de la maîtrise directe côté serveur des dates d'expiration de fichiers statiques volumineux.

6.1.3 Le préchargement

Le préchargement est une fonctionnalité optionnelle qu'un contexte d'interprétation peut mettre en œuvre pour obtenir une ressource avant qu'elle ne soit demandée. Une ressource susceptible d'un préchargement est identifiée par un élément dont l'attribut fetchhint a la valeur "prefetch". Lorsqu'un contexte d'interprétation effectue le préchargement d'une ressource, il doit s'assurer que la ressource préchargée est précisément celle demandée. En particulier, si l'adresse URI est calculée au travers d'un attribut expr, le contexte d'interprétation ne doit pas déplacer le chargement avant les éventuelles assignations des variables de l'expression à évaluer. De même, le chargement effectué à partir d'un élément submit ne doit pas être déplacé avant les éventuelles assignations des variables de l'attribut namelist.

L'état d'expiration d'une ressource doit être vérifié à chaque usage de la ressource et, si la valeur de son attribut fetchhint est "prefetch", elle doit alors être préchargée. La vérification doit suivre la politique de mise en cache définie dans le chapitre 6.1.2.

6.1.4 Les protocoles

Les plateformes VoiceXML doivent prendre en charge le système d'adresse URI http et devraient prendre en charge le protocole https devrait l'être, d'autres protocoles d'adresse URI pouvant être gérés.

6.2 Les informations de métadonnée

Les informations de métadonnée concernent le document plutôt que son contenu. Le langage VoiceXML 2.0 fournit deux éléments pouvant exprimer des informations de métadonnée : les éléments meta et metadata. L'élément metadata offre un traitement plus général et plus puissant des informations de métadonnée que l'élément meta.

Le langage VoiceXML ne définit pas d'informations de métadonnée obligatoires. Cependant, il recommande que les métadonnées soient exprimées au moyen de l'élément metadata, les informations étant fournies dans le langage du cadre de description des ressources (RDF) [RDF-SYNTAX] en utilisant le schéma RDF de l'initiative Dublin Core version 1.0 [DC] (voir le chapitre 6.2.2).

6.2.1 L'élément meta

L'élément meta définit des métainformations comme dans le langage [HTML]. Il existe deux types d'élément meta.

Le premier type définit une propriété de métadonnée du document dans son ensemble et s'exprime au travers du couple d'attributs name et content. Par exemple, pour indiquer la personne chargée de la mise à jour d'un document VoiceXML :

<?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"> 
  <meta name="maintainer" content="dupond@unesociete.example.com"/>
  <form>
    <block>  
       <prompt>Bonjour</prompt> 
    </block>
  </form>  
</vxml>

Le second type définit des en-têtes de réponse HTTP et s'exprime au travers du couple d'attributs http-equiv et content. Dans l'exemple suivant, le premier élément meta fixe une date d'expiration qui empêche la mise en cache du document, le second élément meta fixe l'en-tête Date :

<?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"> 
  <meta http-equiv="Expires" content="0"/> 
  <meta http-equiv="Date"    content="Thu, 12 Dec 2000 23:27:21 GMT"/> 
  <form>
    <block>  
       <prompt>Bonjour</prompt> 
    </block>
  </form>  
</vxml>

Les attributs de l'élément meta sont :

On doit définir exactement un seul d'entre les attributs name ou http-equiv, sinon un événement error.badfetch est suscité.

6.2.2 L'élément metadata

L'élément metadata est un conteneur dans lequel on peut placer des informations contenant le document en utilisant un schéma de métadonnées. Bien qu'on puisse utiliser n'importe quel schéma de métadonnées avec l'élément metadata, on recommande d'utiliser le schéma RDF en conjonction avec les propriétés de métadonnée définies dans l'initiative pour les métadonnées Dublin Core.

Le langage RDF est un langage déclaratif qui permet un emploi normalisé du langage XML pour représenter des métadonnées sous forme de déclarations sur les propriétés et les relations des éléments sur le Web. Les créateurs de contenu devrait consulter les recommandations sur les métadonnées du W3C [RDF-SYNTAX] et [RDF-SCHEMA] ainsi que l'initiative pour les métadonnées Dublin Core [DC], qui est un ensemble de propriétés de métadonnée élémentaires d'application générale (par exemple, Title, Creator, Subject, Description, Copyrights, etc.).

On recommande l'emploi des propriétés de métadonnée Dublin Core suivantes dans l'élément metadata :

Voici un exemple sur la façon d'inclure des métadonnées dans un document VoiceXML en utilisant le schéma RDF de l'initiative Dublin Core version 1.0 [DC] :

<?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"> 
<metadata>
   <rdf:RDF
       xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
       xmlns:rdfs = "http://www.w3.org/TR/1999/PR-rdf-schema-19990303#"
       xmlns:dc = "http://purl.org/metadata/dublin_core#">

<!-- Métadonnées concernant le document VoiceXML -->
   <rdf:Description about="http://www.example.com/meta.vxml"
       dc:Title="Service de renseignement de l'annuaire"
       dc:Description="Service de renseignement de l'annuaire de Londre en VoiceXML"
       dc:Publisher="W3C"
       dc:Language="fr"
       dc:Date="2002-02-12"
       dc:Rights="Copyright 2002 John Smith"
       dc:Format="application/voicexml+xml" >                
       <dc:Creator>
          <rdf:Seq ID="CreateursNomOrdreAlphabétique">
             <rdf:li>Jackie Crystal</rdf:li>
             <rdf:li>William Lee</rdf:li>
          </rdf:Seq>
       </dc:Creator>
   </rdf:Description>
  </rdf:RDF>
 </metadata>
 <form>
    <block>  
       <prompt>Bonjour</prompt> 
    </block>
 </form>  
</vxml>

6.3 L'élément property

L'élément property fixe la valeur d'une propriété. On se sert des élément property pour fixer des valeurs qui affectent le comportement de la plateforme, comme le traitement de reconnaissance, les délais, la politique de mise en cache, etc.

On peut définir des propriétés pour l'application entière, pour le document entier au niveau de l'élément vxml, pour un dialogue particulier au niveau des éléments form ou menu, ou pour un élément de formulaire particulier. Les propriétés s'appliquent à leur élément parent et à tous les descendants du parent. Une propriété à un niveau inférieur surclasse une propriété à un niveau supérieur. Lorsque des valeurs différentes sont définies pour une propriété sur un même niveau, c'est la dernière dans l'ordre du document qui s'applique. Les propriétés définies dans le document racine d'application fournissent les valeurs implicites des propriétés dans chaque document de l'application ; les propriétés définies dans un document individuel surclassent les valeurs de propriété définies dans le document racine d'application.

Si une plateforme détecte l'invalidité de la valeur d'une propriété, alors elle devrait susciter un événement error.semantic.

Dans certains cas, les éléments property définissent des valeurs par défaut pour les attributs d'un élément, tels que timeout et bargein. Par exemple, pour supprimer l'interruption implicite de toutes les invites d'un formulaire particulier :

<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="formulaire_sans_interruption"> 
  <property name="bargein" value="false"/> 
  <block> 
    <prompt>
      Cette invite d'introduction ne peut pas être interrompue.
    </prompt> 
    <prompt>
      Tout comme celle-ci.
    </prompt> 
    <prompt bargein="true">
      Mais celle-ci <emphasis>peut</emphasis> être interrompue.
    </prompt> 
  </block> 
  <field type="boolean">
    <prompt>
      Veuillez dire oui ou non.
    </prompt>
  </field>  
</form>
</vxml>

Les attributs de l'élément property sont :

6.3.1 Les propriétés propres à la plateforme

Un contexte d'interprétation est libre de fournir des propriétés propres à la plateforme. Par exemple, pour fixer le facteur de multiplication de cette plateforme dans la portée de ce document :

<?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>
  <property name="com.example.facteur_multiplication" value="42"/> 
  <block> 
    <prompt> Bienvenue </prompt> 
  </block>
</form>  
</vxml>

Par définition, les propriétés propres à une plateforme introduisent des incompatibilités qui peuvent nuire à la portabilité d'une application. Pour les minimiser, on recommande fortement de suivre les conseils suivants pour le contexte d'interprétation :

• Les propriétés propres à une plateforme devraient utiliser des noms de domaine inversés afin d'éliminer des collisions potentielles comme, par exemple, com.example.foo qui se différencie nettement de net.example.foo

• Le contexte d'interprétation ne doit pas susciter un événement error.unsupported.property lorsqu'il rencontre une propriété qu'il ne peut pas traiter et devrait plutôt simplement l'ignorer.

6.3.2 Les propriétés génériques des logiciels de reconnaissance vocale

Les propriétés génériques des logiciels de reconnaissance vocale proviennent pour la plupart de l'interface Java Speech API [JSAPI] :

6.3.3 Les propriétés génériques des logiciels de reconnaissance DTMF

Plusieurs propriétés génériques concernent la reconnaissance des grammaires DTMF :

6.3.4 Les propriétés d'invite et de collecte

Ces propriétés s'appliquent au cycle fondamental d'invite et de collecte de la plateforme :

6.3.5 Les propriétés de mise en place

Ces propriétés concernent les nouveaux chargements de documents et de ressources (remarquez que les propriétés maxage et maxstale peuvent ne pas avoir de valeur par défaut : voir le chapitre 6.1.2) :

6.3.6 Les propriétés diverses

Notre dernier exemple montre quelques unes de ces propriétés dans plusieurs niveaux :

<?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">
  <!-- Fixe les caractéristiques par défaut de la page --> 
  <property name="audiofetchhint" value="safe"/> 
  <property name="confidencelevel" value="0.75"/>

  <form> 
    <!-- Surclasse les valeurs par défaut pour ce seul formulaire --> 
    <property name="confidencelevel" value="0.5"/> 
    <property name="bargein" value="false"/> 
    <grammar src="carnet_adresses.grxml" type="application/srgs+xml"/>
    <block> 
      <prompt> Bienvenue sur le carnet d'adresse vocal </prompt> 
    </block> 
    <initial name="start"> 
      <!-- Surclasse les valeurs d'expiration par défaut --> 
      <property name="timeout" value="5s"/> 
      <prompt> Voulez-vous appeler cette personne ? </prompt> 
    </initial> 
    <field name="personne"> 
      <prompt>
        Dites le nom de la personne que vous souhaitez appeler.
      </prompt> 
    </field> 
    <field name="ville"> 
      <prompt>
        Dites la ville de la personne que vous souhaitez appeler.
      </prompt> 
    </field> 
    <field name="confirmer"> 
     <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>
      <!-- Utiliser l'énoncé réel pour jouer les mots reconnus, 
              plutôt que les valeurs de facette renvoyées --> 
      <prompt> 
        Vous souhaitez appeler <value expr="personne$.utterance"/> 
        à <value expr="ville$.utterance"/>. 
        Est-ce exact ? 
      </prompt> 
      <filled> 
        <if cond="confirmer"> 
          <submit namelist="personne ville"
            next="http://www.centralmessage.example.com/voix/appeler" />
        </if> 
        <clear/> 
      </filled> 
    </field> 
  </form> 
</vxml>

6.4 L'élément param

L'élément param sert à indiquer les valeurs qui seront passées aux sous-dialogues ou aux objets. Il s'inspire de l'élément [HTML] <PARAM>. Ses attributs sont :

On doit définir exactement un seul d'entre les attributs expr ou value, sinon un événement error.badfetch est suscité.

L'emploi des attributs valuetype et type est, en général, optionnel, bien qu'ils puissent être exigés par des objets particuliers. Lorsque les éléments param sont contenus dans un élément subdialog, les valeurs qu'ils indiquent servent à initialiser les éléments var du sous-dialogue invoqué. Voir le chapitre 2.3.4 pour des précisions à propos de l'initialisation des variables dans les sous-dialogues utilisant des éléments param. Lorsque les éléments param sont contenus dans un élément object, l'utilisation qui est faite des données des paramètres est propre à l'objet invoqué, et n'est pas décrite dans la spécification VoiceXML.

Voici un exemple avec des éléments param faisant partie d'un élément object. Dans ce cas, les deux premiers éléments param comportent des expressions (implicitement valuetype="data"), le troisième param a une valeur explicite et le quatrième est une adresse URI qui renvoie le type de média "text/plain". La signification de ces données est particulière à l'objet :

<object name="debit" 
 classid="method://carte-credit/collecter_et_debiter" 
 data="http://www.enregistrements.example.com/invites/credit/jesse.jar"> 
  <param name="amount" expr="document.amt"/> 
  <param name="vendor" expr="num_vendeur"/> 
  <param name="application_id" value="ADC5678-QWOO"/> 
  <param name="serveur_authentification"
   value="http://serv-auth.example.com" 
   valuetype="ref"
   type="text/plain"/> 
</object>

L'exemple suivant montre des éléments param avec un élément subdialog. Dans ce cas, on utilise deux expressions pour initialiser les variables dans la portée du formulaire du sous-dialogue :

Le formulaire avec un dialogue appelant

<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> 
  <subdialog name="resultat" src="http://autre.example.com/#obtenir_nss"> 
    <param name="prenom" expr="document.le_prenom"/> 
    <param name="nom"  expr="document.le_nom"/> 
    <filled> 
      <submit namelist="resultat.nss"
        next="http://unservice.example.com/cgi-bin/traitement"/> 
    </filled> 
  </subdialog> 
</form>
</vxml>

Le sous-dialogue situé à http://autre.example.com

 <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_nss"> 
  <var name="prenom"/> 
  <var name="nom"/> 
  <field name="nss"> 
      <grammar src="http://grammaires/nss.grxml"
        type="application/srgs+xml"/>
      <prompt>
        Veuillez indiquer un numéro de sécurité sociale.
      </prompt> 
      <filled> 
        <if cond="nss_valide(prenom,nom,nss)"> 
          <assign name="statut" expr="true"/> 
          <return namelist="statut nss"/> 
        <else/> 
          <assign name="statut" expr="false"/> 
          <return namelist="statut"/> 
        </if> 
      </filled> 
  </field> 
</form>
</vxml>

L'utilisation d'éléments param dans un élément subdialog représente un moyen commode de passer des données à un sous-dialogue sans devoir faire appel à un script côté serveur.

6.5 Les désignations des valeurs

Plusieurs valeurs de paramètre VoiceXML suivent les conventions employées dans la recommandation des feuilles de style en cascade du W3C [CSS2].

6.5.1 Les entiers et les nombres réels

Les nombres réels et les entiers s'expriment seulement en notation décimale. Un entier se compose d'un ou plusieurs chiffres de "0" à "9". Un nombre réel peut apparaître comme un entier ou se composer de zéro chiffre ou plus, suivis par un point (.), suivi par un ou plusieurs chiffres. Les entiers comme les nombres réels peuvent être précédés par un caractère moins - ou plus + pour en indiquer le signe.

6.5.2 Les temps

Les désignations de temps se composent d'un nombre réel non négatif suivi d'un identifiant d'unité de temps. Les identifiants d'unité de temps sont :

• ms : la milliseconde
• s : la seconde

Exemples : "3s", "850ms", "0.7s", ".5s" et "+1.5s".

Annexes

Annexe A : Le glossaire des termes

algorithme FIA (Form Interpretation Algorithm)

L'algorithme mis en œuvre dans un interpréteur VoiceXML qui conduit l'interaction entre l'utilisateur et un formulaire ou un menu VoiceXML. Voir le chapitre 2.1.6 et l'annexe C.

application

Une collection de documents VoiceXML étiquetés d'un attribut application ayant la même valeur.

ASR

Automatic speech recognition.

auteur

Le créateur d'un document VoiceXML.

contenu exécutable

Une logique procédurale qui se déroule dans les éléments block, les éléments filled ou dans les gestionnaires d'événement.

contexte d'interprétation VoiceXML

Un logiciel qui emploie un interpréteur VoiceXML pour interpréter un document VoiceXML et qui peut également interagir avec la plateforme d'implémentation indépendamment de l'interpréteur VoiceXML.

dialogue

Une interaction avec l'utilisateur définie dans un document VoiceXML. Les dialogues sont de plusieurs types : les formulaires et les menus.

document VoiceXML

Un document XML conforme à la spécification VoiceXML.

DTMF (Dual Tone Multi-Frequency)

Une composition par tonalités ou par touches. La pression d'un bouton sur un clavier téléphonique génère un son qui est la combinaison de deux tonalités : l'une de haute fréquence et l'autre de basse fréquence.

ECMAScript

Une version normalisée du langage JavaScript soutenue par l'European Computer Manufacturer's Association. Voir [ECMASCRIPT]

élément de capture

Un bloc catch ou l'une de ses formes abrégées. Certains éléments de capture sont définis par l'interpréteur VoiceXML.

élément de commande

Un élément de formulaire destiné soit à contenir un bloc de procédures logiques (block), soit à permettre les invites initiales d'un dialogue à initiative mixte (initial).

élément d'entrée

Un élément de formulaire destiné à entrer une variable d'élément d'entrée. Les éléments d'entrée comprennent les éléments field, record, object, subdialog et transfer.

élément de formulaire

Un élément contenu dans un élément form susceptible d'être visité au cours de l'exécution du formulaire : initial, block, field, record, object, subdialog et transfer.

événement

Une notification lancée par la plateforme d'implémentation, le contexte d'interprétation VoiceXML, l'interpréteur VoiceXML ou un code VoiceXML. Les événements incluent les conditions exceptionnelles (les erreurs sémantiques), les erreurs normales (l'utilisateur veut quitter) et les événements définis par l'utilisateur.

formulaire

Un dialogue qui interagit avec l'utilisateur de manière très souple, l'ordinateur et l'utilisateur partageant l'initiative.

grammaire active

Une grammaire vocale ou DTMF actuellement active. On le détermine à partir de l'élément en cours d'exécution et des éléments scope des grammaires actuellement définies.

identificateur de langue

Un identificateur de langue étiquette un contenu d'informations comme étant dans une variante d'une langue humaine particulière. D'après la spécification XML pour l'identification d'une langue [XML], un identificateur de langue légal est déterminé par un code RFC 3066 [RFC3066]. Selon le document RFC 3066, le code de langue est obligatoire et le code de pays, ou une autre sous-étiquette d'identificateur, est optionnel.

initiative mixte

Une interaction homme-machine selon laquelle soit l'ordinateur, soit l'humain prend l'initiative et décide quoi faire ensuite.

interpréteur VoiceXML

Un logiciel qui interprète un document VoiceXML afin de contrôler une plateforme d'implémentation dans le but de conduire une interaction avec un utilisateur.

invites dégressives

Un ensemble d'invites utilisé pour varier le message donné à un humain. Les invites peuvent être réduites afin d'être plus concises à l'usage (invite de champ) ou plus explicites (invite d'assistance).

JSGF

Java API Speech Grammar Format. Un standard proposé pour représenter des grammaires vocales. Voir [JSGF]

link

Un ensemble de grammaires qui, l'utilisateur ayant dit ou saisi quelque chose qui y trouve une correspondance, opère une transition vers un nouveau dialogue, ou un nouveau document, ou bien qui suscite un événement dans l'élément de formulaire courant.

menu

Un dialogue qui présente un ensemble de choix à l'utilisateur et entreprend une action en fonction de la sélection.

objet

Une fonctionnalité propre à une plateforme disposant d'une interface via VoiceXML.

plateforme d'implémentation

Un ordinateur pourvu du logiciel et/ou du matériel adéquats permettant de gérer les types d'interaction définis par VoiceXML.

requête

Une collection de données comprenant : une adresse URI indiquant un serveur de documents pour les données, un ensemble de couples nom/valeur des données à traiter (optionnel) et une méthode de soumission pour le traitement (optionnel).

script

Un fragment de logique écrit dans un langage de script côté client, en particulier le langage de script ECMAScript lequel doit être pris en charge par tout interpréteur VoiceXML.

session

Une connexion entre un utilisateur et une plateforme d'implémentation, par exemple, un appel téléphonique vers un système de réponse vocale. Une session peut impliquer l'interprétation de plusieurs documents VoiceXML.

sous-dialogue

Un dialogue (ou un document) VoiceXML invoqué depuis le dialogue courant de manière analogue à un appel de fonction.

Spécification des feuilles de style en cascade du W3C.

Voir [CSS2]

SRGS (Speech Recognition Grammar Specification)

Un format normalisé pour les grammaires de reconnaissance vocale à contexte libre en cours de développement par le groupe de travail Navigateur vocal du W3C. Les formats ABNF et XML sont tous deux définis [SRGS].

SSML (Speech Synthesis Markup Language)

Un format normalisé pour la synthèse de la parole en cours de développement par le groupe de travail Navigateur vocal du W3C [SSML].

throw

Un élément qui déclenche un événement.

TTS

text-to-speech : synthèse de la parole.

URI

Uniform Resource Indicator.

URL

Uniform Resource Locator.

utilisateur

Une personne dont l'interaction avec une plateforme d'implémentation est contrôlée par un interpréteur VoiceXML.

variable d'élément de formulaire

Une variable, définie implicitement ou bien explicitement, associée à chaque élément de formulaire dans un formulaire. Si la variable d'élément de formulaire n'est pas définie, l'algorithme FIA visitera l'élément de formulaire et l'utilisera pour interagir avec l'utilisateur.

W3C

World Wide Web Consortium http://www.w3.org/

Annexe B : La définition de type de document VoiceXML

Le DTD de VoiceXML se trouve à http://www.w3.org/TR/voicexml20/vxml.dtd.

En raison des limitations des DTD, le DTD de VoiceXML n'exprime pas correctement le fait que l'élément metadata puisse contenir des éléments issus d'autres espaces de nommage XML.

Remarque : Le DTD de VoiceXML contient des éléments modifiés provenant des DTD de la spécification des grammaires de reconnaissance vocale 1.0 [SRGS] et du langage de balisage de la synthèse vocale  [SSML].

Annexe C : L'algorithme d'interprétation des formulaires

L'algorithme d'interprétation des formulaires (FIA) conduit l'interaction entre l'utilisateur et un formulaire, ou un menu, VoiceXML. On peut assimiler un menu à un formulaire contenant un seul champ dont la grammaire et l'action filled sont construites à partir des éléments choice.

L'algorithme FIA doit prendre en charge :

• L'initialisation du formulaire.
• Le mécanisme des invites, y compris la gestion des compteurs d'invites qui est nécessaire à la réduction des invites.
• L'activation et la désactivation des grammaires au niveau du formulaire et des éléments de formulaire.
• L'entrée dans le formulaire avec un énoncé qui correspondait à l'une des grammaires de portée document du formulaire alors que l'utilisateur visitait un formulaire ou un menu différents.
• La sortie du formulaire parce que l'utilisateur a touché une autre grammaire de portée document d'un formulaire, d'un menu ou d'un lien.
• Le traitement de plusieurs remplissages de champs à partir d'un seul énoncé, y compris l'exécution des actions filled concernées.
• La sélection de l'élément de formulaire suivant à visiter puis son traitement.
• Le choix du bon élément de capture pour gérer les éventuels événements suscités au cours du traitement d'un élément de formulaire.

Nous définissons d'abord quelques termes et structures de données utilisés dans l'algorithme d'interprétation des formulaires :

jeu de grammaires actif

L'ensemble des grammaires actives au cours de l'opération de collecte des entrées par le contexte d'interprétation VoiceXML.

énoncé

Un résumé de ce que l'utilisateur a dit ou saisi, y compris la grammaire particulière qui correspond, et un résultat sémantique consistant en une structure d'interprétation ou, quand il n'y a pas d'interprétation sémantique, le texte brut de l'entrée (voir le chapitre 3.1.6). Un exemple d'énoncé : la grammaire 123 correspond et l'interprétation sémantique est {boisson: "eau" pizza: {numero: "3" taille: "grande"}}.

exécuter

Exécuter un contenu exécutable soit un élément block, soit une action filled ou un ensemble d'actions filled. Si un événement est suscité au cours de l'exécution, l'exécution du contenu exécutable est abandonnée. Le gestionnaire d'événement adéquat est alors exécuté, ce qui peut entraîner une reprise du contrôle dans un élément de formulaire, dans l'itération suivante de la boucle principale du formulaire ou bien en dehors du formulaire. Si un élément goto est exécuté, le transfert intervient immédiatement, et le reste du contenu exécutable ne sera pas exécuté.

Voici l'algorithme d'interprétation des formulaires présenté de manière conceptuelle. L'algorithme FIA peut démarrer sans énoncé initial ou avec un énoncé initial passé par un autre dialogue :

//
// Phase d'initialisation
//

foreach ( var, script et élément de formulaire, dans l'ordre du document )
   if ( l'élément est un var )
     Déclarer la variable, en l'initialisant à la valeur de
     l'attribut expr, le cas échéant, ou sinon à "undefined".
   else if ( l'élément est un script )
     Évaluer le contenu du script si inscrit directement ou sinon
     depuis l'emplacement défini par l'attribut src.
   else if ( l'élément est un élément de formulaire )
     Créer une variable à partir de l'attribut name, le cas échéant, ou
     sinon générer un nom interne. Assigner à cette variable
     la valeur de l'attribut expr, le cas échéant, ou sinon "undefined".
            foreach ( élément d'entrée et élément initial )
                 Declare a prompt counter and set it to 1.

if ( l'utilisateur est entré dans ce formulaire via une parole
      en correspondance à sa grammaire alors qu'il était
      dans un autre formulaire )
{
    Entrer dans la boucle principale ci-dessous, mais commencer
    dans la phase de traitement et non dans celle de sélection :
    on a déjà une collection à traiter.
}

//
// Boucle principale : Sélectionner l'élément de formulaire suivant et l'exécuter.
//

while ( true )
{
    //
    // Phase de sélection : Choisir un élément de formulaire à visiter.
    //

    if ( la dernière itération de la boucle principale a terminé
              par un <goto nextitem> )
        Sélectionner cet élément de formulaire suivant.

    else if ( il existe un élément de formulaire ayant une
              condition de veille non satisfaite )
        Sélectionner le premier de ces éléments de formulaire, dans l'ordre du document.

    else
        Effectuer un exit -- le formulaire est rempli et ne définissait pas de transition.

    //
    // Phase de collecte : Exécuter l'élément de formulaire sélectionné.
    //
    // Mettre en file d'attente les invites de l'élément de formulaire.

    unless ( à moins que la dernière itération de la boucle n'a terminé par
            une capture sans reprompt
            et que le dialogue actif n'a pas été changé )
    {

        Sélectionner les invites appropriées pour un élément d'entrée ou initial.
        Mettre en file d'attente les invites sélectionnées en vue d'une lecture
        avant l'opération de collecte suivante.

        Incrémenter le compteur d'invites de l'élément d'entrée ou l'élément initial.
    }

    // Activer les grammaires de l'élément de formulaire.

    if ( l'élément de formulaire est modal )
        Fixer le jeu des grammaires actives sur les grammaires de l'élément de formulaire,
        le cas échéant. (Remarquez que certains éléments de formulaire, par exemple,
        block, ne peuvent pas avoir de grammaire).
    else
        Fixer le jeu des grammaires actives sur les grammaires de l'élément de formulaire
        et les éventuelles grammaires dans la portée du formulaire,
        du document courant et du document racine d'application.

    // Exécuter l'élément de formulaire.

    if ( un élément field a été sélectionné )
        Collecter un énoncé ou un événement issus de l'utilisateur.
    else if ( un élément record a été choisi )
        Collecter un énoncé (avec un couple nom/valeur pour les octets enregistrés)
        ou un événement issus de l'utilisateur.
    else if ( un élément object a été choisi )
        Exécuter l'objet, en fixant la variable d'élément de formulaire de
        l'object à la valeur ECMAScript renvoyée.
    else if ( un élément subdialog a été choisi )
        Exécuter le sous-dialogue, en fixant la variable d'élement de formulaire
        du subdialog à la valeur ECMAScript renvoyée.
    else if ( un élément transfer a été choisi )
        Effectuer le transfert et (si wait="true") fixer la
        variable d'élément de formulaire de transfer
        à l'indicateur de statut du résultat renvoyé.
    else if ( un élément initial a été choisi )
        Collecter un énoncé ou un événement issus de l'utilisateur.
    else if ( un élément block a été choisi )
    {
        Fixer la variable d'élément de formulaire du block
        à une valeur définie.

        Exécuter le contenu exécutable du block.
    }

    //
    // Phase de traitement : Traiter l'énoncé ou l'événement résultant.
    //

    Assigner l'énoncé et les autres informations concernant la dernière
    reconnaissance à application.lastresult$.
            // Doit avoir un énoncé

    if ( l'énoncé correspondait à une grammaire appartenant à un link )
      Si l'élément link définit un attribut next ou expr,
      effectuer la transition vers cette adresse. Sinon, si l'élément link
      définit un attribut event ou eventexpr,
      générer cet événement.
    else if ( l'énoncé correspondait à une grammaire appartenant à un choice )
      Si l'élément choice définit un attribut next ou expr,
      effectuer la transition vers cette adresse. Sinon, si l'élément choice
      définit un attribut event ou eventexpr,
      générer cet événement.
    else if ( l'énoncé correspondait à une grammaire située hors du form ou menu courant )
    {
      Effectuer la transition vers cet élément form ou menu,
      en apportant l'énoncé à la nouvelle instance FIA.
    }

    // Traiter un énoncé sollicitant une grammaire provenant de ce formulaire.
    // Copier d'abord les valeurs de propriété du résultat de l'énoncé dans les
    // variables d'élément de formulaire correspondantes.

    Effacer tous les drapeaux juste_rempli.

    if ( la grammaire est dans la portée du niveau champ ) {
       // Cette grammaire doit être incluse dans un élément d'entrée. L'élément d'entrée
       // a une variable ECMAScript associée (appelée ici variable d'élément d'entrée)
       // et un nom de facette.

       if ( le résultat n'est pas une structure )
         Copier le résultat dans la variable d'élément d'entrée.
       elseif ( une propriété de niveau supérieur dans le résultat correspond au nom de facette
                ou le nom de facette est un chemin séparé par des points correspondant à une
                sous-propriété dans le résultat )
         Copier la valeur de cette propriété dans la variable d'élément d'entrée.
       else
         Copier le résultat entier dans la variable d'élément d'entrée

       Fixer le drapeau juste_rempli de cet élément d'entrée.
    }
    else {
       foreach ( propriété dans l'énoncé de l'utilisateur )
       {
          if ( la propriété correspond au nom de facette d'un élément d'entrée )
          {
             Copier la valeur de cette propriété dans la variable d'élément de formulaire de
             cet élément d'entrée.

             Fixer le drapeau juste_rempli de cet élément d'entrée.
          }
       }
    }


    // Fixer toutes les variables d'élément de formulaire de l'élément initial,
    // si chaque élément d'entrée est rempli.

    if ( toute variable d'élément d'entrée est fixée en résultat de l'énoncé de l'utilisateur )
        Fixer toutes les variables d'élément de formulaire de initial à "true".

    // Exécuter ensuite toutes les actions déclenchées par filled. 

    foreach ( action filled dans l'ordre du document )
    {
        // Déterminer les variables d'élément d'entrée auxquelles le filled s'applique.

        N = l'attribut namelist de l'élément filled.

        if ( N égale "" )
        {
           if ( l'élément filled est un enfant d'élément d'entrée )
             N = le nom de la variable d'élément de formulaire de l'élément d'entrée.
           else if ( l'élément filled est un enfant de form )
             N = les noms des variables d'élément de formulaire de tous les
                 éléments d'entrée dans ce formulaire.
        }

        // Est-ce que le filled est déclenché ?

        if ( toute variable d'élément d'entrée du jeu N a été juste_remplie
               ET  (  l'attribut mode de l'élément filled a la valeur "all"
                           ET toutes les variables dans N sont remplies
                       OU l'attribut mode de l'élément filled a la valeur "any"
                           ET toutes les variables dans N sont remplies ) )
             Exécuter l'action filled.

         Si un événement est suscité au cours de l'exécution d'un élément filled,
             la sélection du gestionnaire d'événement commence dans la portée de l'élément filled,
         qui pourrait être celle d'un élément d'entrée ou le formulaire en question.
    }
    // Si aucun élément d'entrée n'est rempli, juste continuer.
}

Annexe D : Les propriétés de temporisation

Les diverses propriétés de temporisation pour la reconnaissance vocale et DTMF s'accordent pour définir l'expérience d'utilisateur. Les modalités selon lesquelles ces différents paramètres de temporisation fonctionnent sont soulignées dans les diagrammes de temporisation ci-dessous. Dans ces diagrammes, le début d'attente d'une entrée DTMF ou d'une parole de l'utilisateur commence au moment où la dernière invite a fini de jouer.

D.1. Les grammaires DTMF

Les grammaires DTMF utilisent les propriétés timeout, interdigittimeout, termtimeout et termchar, décrites dans le chapitre 6.3.3, pour adapter l'expérience d'utilisateur. Leurs effets sont montrés dans les diagrammes de temporisation suivants :

La propriété timeout quand aucune entrée n'est fournie

Le paramètre timeout détermine le moment où l'événement noinput est suscité, parce que l'utilisateur n'a entré aucune tonalité DTMF (Figure 12). Dès que la première tonalité DTMF a été entrée, ce paramètre n'a plus aucun effet.

Figure 12 : Diagramme de temporisation de la propriété timeout quand aucune entrée n'est fournie.

La propriété interdigittimeout quand la grammaire n'est pas prête à terminer

Dans la figure 13, la propriété interdigittimeout détermine le moment où l'événement nomatch est suscité, parce qu'une grammaire DTMF n'est pas encore reconnue et que l'utilisateur n'a pas entré d'autre tonalité DTMF.

Figure 13 : Diagramme de temporisation de la propriété interdigittimeout quand la grammaire n'est pas prête à terminer.

La propriété interdigittimeout quand la grammaire est prête à terminer

L'exemple ci-dessous montre une situation où une grammaire DTMF pourrait terminer ou se prolonger par l'entrée d'autres tonalités DTMF, tandis que l'utilisateur ne s'est pas décidé à fournir une autre entrée.

Figure 14 : Diagramme de temporisation de la propriété interdigittimeout quand la grammaire est prête à terminer.

Les propriétés termchar et interdigittimeout quand la grammaire peut terminer

Dans l'exemple ci-dessous, la propriété termchar n'est pas vide et sa valeur est entrée par l'utilisateur avant l'expiration définie par la propriété interdigittimeout, signifiant ainsi que l'entrée DTMF de l'utilisateur est complète ; le caractère de terminaison n'est pas inclus avec la valeur reconnue.

Figure 15 : Diagramme de temporisation des propriétés termchar et interdigittimeout quand la grammaire peut terminer.

La propriété termchar vide quand la grammaire doit terminer

Dans l'exemple ci-dessous, l'entrée de la dernière tonalité DTMF a mené la grammaire à un point de terminaison auquel on n'attend pas d'autre tonalité DTMF. Comme la propriété termchar est vide, aucun caractère de terminaison optionnel n'est autorisé : la reconnaissance se termine donc et la valeur reconnue est renvoyée.

Figure 16 : Diagramme de temporisation de la propriété termchar vide quand la grammaire doit terminer.

Les propriétés termchar non vide et termtimeout quand la grammaire doit terminer

Dans l'exemple ci-dessous, l'entrée de la dernière tonalité DTMF a mené la grammaire à un point de terminaison auquel la grammaire n'autorise aucune autre tonalité DTMF. Si la propriété termchar est non vide, alors l'utilisateur peut entrer un caractère de terminaison DTMF optionnel dans l'intervalle défini par la propriété termtimeout : la reconnaissance se termine alors et la valeur reconnue est renvoyée. Si la valeur de la propriété termtimeout est "0s" (la valeur implicite), alors la valeur reconnue est renvoyée immédiatement après la dernière tonalité DTMF autorisée par la grammaire, sans attendre le caractère de terminaison optionnel. Remarque : la propriété termtimeout s'applique seulement quand la grammaire n'autorise aucune autre entrée, sinon, la propriété interdigittimeout s'appliquera.

Figure 17 : Diagramme de temporisation de la propriété termchar non vide et de la propriété termtimeout quand la grammaire doit terminer.

Les propriétés termchar non vide et termtimeout quand la grammaire doit terminer

Dans cet exemple, l'entrée de la dernière tonalité DTMF a mené la grammaire à un point de terminaison auquel la grammaire n'autorise aucune autre tonalité DTMF. Puisque la propriété termchar est non vide, l'utilisateur entre le caractère de terminaison optionnel dans l'intervalle défini par la propriété termtimeout, provoquant ainsi le retour de la valeur reconnue (en excluant le caractère de terminaison).

Figure 18 : Diagramme de temporisation de la propriété termchar non vide quand la grammaire doit terminer.

Les entrées DTMF invalides

En attendant la première ou d'autres tonalités DTMF, trois délais différents peuvent déterminer l'instant où l'entrée d'utilisateur sera considérée comme complète : si aucune tonalité DTMF n'a été entrée, la propriété timeout s'appliquera ; si une certaine tonalité DTMF a été entrée, une tonalité supplémentaire étant valide, alors la propriété interdigittimeout s'appliquera, et si aucune autre tonalité DTMF n'est valide, la propriété termtimeout s'applique alors. Dans chaque cas, l'utilisateur peut entrer une tonalité DTMF interdite par la ou les grammaires actives. Ce qui entraîne l'invalidité de la chaîne DTMF collectée. D'autres chiffres seront collectés jusqu'à ce que la touche du caractère de terminaison soit appuyée ou bien jusqu'à ce que la valeur indiquée par la propriété interdigittimeout soit dépassée. Un événement nomatch est alors généré.

D.2. Les grammaires vocales

Les grammaires vocales utilisent les propriétés timeout, completetimeout et incompletetimeout, décrites dans le chapitre 6.3.4 et le chapitre 6.3.2, pour adapter l'expérience d'utilisateur. Leurs effets sont montrés dans les diagrammes de temporisation suivants :

La propriété timeout quand rien n'est dit

Dans l'exemple ci-dessous, la propriété timeout détermine quand l'événement noinput est suscité, parce que l'utilisateur n'a rien dit.

Figure 19 : Diagramme de temporisation de la propriété timeout quand rien n'est dit.

La propriété completetimeout avec une grammaire vocale reconnue

Dans l'exemple précédent, l'utilisateur fournissait un énoncé qui était reconnu par la grammaire vocale. Après l'écoulement de la période de silence indiquée par la propriété completetimeout, la valeur reconnue est renvoyée.

Figure 20 : Diagramme de temporisation de la propriété completetimeout avec une grammaire vocale reconnue.

La propriété incompletetimeout avec une grammaire vocale non reconnue

Dans l'exemple précédent, l'utilisateur fournissait un énoncé qui n'était pas encore reconnu par la grammaire vocale tout en étant le préfixe d'un énoncé légal. Après l'écoulement de la période de silence indiquée par la propriété incompletetimeout, un événement nomatch est suscité.

Figure 21 : Diagramme de temporisation de la propriété incompletetimeout avec une grammaire vocale non reconnue.

Annexe E : Les formats des fichiers sons

Le langage VoiceXML demande à une plateforme qu'elle gère la lecture et l'enregistrement des formats audio définis ci-dessous :

Le type MIME "audio/basic" s'utilise couramment avec le format d'en-tête au ainsi qu'avec le format 8-bit 8Khz mu-law sans en-tête. Si ce type MIME est indiqué pour l'enregistrement, on doit utiliser le format mu-law. Pour la lecture avec le type MIME "audio/basic", les plateformes doivent gérer le format mu-law et elles peuvent gérer le format au.

Annexe F : La conformité

Ce chapitre est normatif.

F1. Le document VoiceXML conforme

Un document VoiceXML conforme est un document [XML] bien formé qui ne nécessite que les facilités décrites comme obligatoires dans cette spécification. Un tel document doit satisfaire à tous les critères suivants :

1. Le document doit se conformer aux contraintes exprimées dans le schéma VoiceXML (voir l'annexe O).

2. L'élément racine du document doit être l'élément vxml.

3. L'élément vxml doit inclure un attribut version avec la valeur "2.0".

4. L'élément vxml doit désigner l'espace de nommage VoiceXML. On peut le faire en déclarant un attribut xmlns ou un attribut avec un préfixe xmlns [XMLNAMES]. L'espace de nommage de VoiceXML est défini comme étant http://www.w3.org/2001/vxml.

5. On recommande que l'élément vxml indique également l'emplacement du schéma VoixeXML (voir l'annexe O) via l'attribut xsi:schemaLocation issu de la spécification [SCHEMA1] :

   xsi:schemaLocation="http://www.w3.org/2001/vxml http://www.w3.org/TR/voicexml20/vxml.xsd"

   Bien qu'elle ne soit pas obligatoire, le présent document fournit cette indication dans tous les exemples pour en encourager l'utilisation.

6. Il peut y avoir une déclaration de type de document DOCTYPE dans le document avant l'élément racine. Le cas échéant, l'identificateur public inclus dans la déclaration DOCTYPE doit appeler le DTD de VoiceXML (voir l'annexe B) en utilisant son identifiant public formel :

   <!DOCTYPE vxml 
        PUBLIC "-//W3C//DTD VOICEXML 2.0//EN" 
        "http://www.w3.org/TR/voicexml20/vxml.dtd">
   

   L'identifiant système peut se modifier de manière appropriée.

   On ne doit pas utiliser le sous-ensemble de DTD pour surclasser les entités paramètres dans le DTD.

Voici un exemple de document VoiceXML conforme :

<?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>
  <block>bonjour</block>
 </form>

</vxml>

Remarquez que cet exemple comprend les attributs recommandés xmlns:xsi et xsi:schemaLocation ainsi qu'une déclaration XML. Une déclaration XML comme celle-ci n'est pas obligatoire dans tous les documents. Les auteurs de documents VoiceXML sont fortement encouragés à employer des déclarations XML dans tous leurs documents. Une telle déclaration est obligatoire lorsque le codage des caractères du document diffère des codages implicites UTF-8 ou UTF-16 et qu'aucun codage n'a été déterminé par un protocole de niveau supérieur.

Le langage VoiceXML ou ces critères de conformité n'indiquent aucune limite de taille sur un aspect quelconque des documents VoiceXML. Il n'y a aucune valeur maximum au nombre des éléments, à la quantité des données textuelles ou au nombre de caractères dans les valeurs des attributs.

F.2 L'utilisation du langage VoiceXML avec d'autres espaces de nommage

On peut utiliser l'espace de nommage VoiceXML avec d'autres espaces de nommage XML selon la spécification [XMLNAMES], bien que de tels documents ne soient pas des documents VoiceXML strictement conformes comme défini précédemment. Des travaux ultérieurs du W3C proposeront des moyens d'indiquer la conformité des documents mettant en scène plusieurs espaces de nommage.

F.3 Les processeurs VoiceXML conformes

Un processeur VoiceXML est un agent utilisateur capable d'analyser et de traiter des documents VoiceXML conformes.

Dans un processeur VoiceXML conforme, l'analyseur XML doit pouvoir analyser et traiter toutes les structures XML bien formées définies dans les spécifications [XML] et [XMLNAMES]. Un processeur VoiceXML conforme n'est pas obligé d'utiliser un analyseur validant.

Un processeur VoiceXML conforme doit être un processeur SSML conforme [SSML] et un processeur de grammaire XML conforme [SRGS], sauf pour les différences décrites dans ce document. Si une erreur de syntaxe est détectée au cours du traitement d'un document de grammaire, alors un événement error.badfetch doit être suscité.

Un processeur VoiceXML conforme doit gérer la syntaxe et la sémantique de tous les éléments VoiceXML décrits dans ce document. Par conséquent, un processeur VoiceXML conforme ne doit pas susciter d'événement error.unsupported.<élément> pour tout élément VoiceXML devant être géré au cours du traitement d'un document VoiceXML conforme.

Lorsqu'un processeur VoiceXML conforme rencontre un document VoiceXML conforme contenant des éléments ou des attributs non-VoiceXML, lesquels sont propriétaires, définis seulement dans des versions précédentes du langage VoiceXML ou bien définis dans un espace de nommage non-VoiceXML et ne pouvant pas être traités, alors il doit susciter un événement error.badfetch.

Lorsqu'un processeur VoiceXML conforme rencontre un document ayant un élément racine qui désigne un espace de nommage autre que celui de VoiceXML, son comportement n'est pas défini.

Toutefois, il n'y a aucune obligation de conformité concernant les caractéristiques des performances du processeur VoiceXML.

Annexe G : L'internationalisation

Le langage VoiceXML est une application du langage [XML] et, de ce fait, gère [UNICODE] qui définit un jeu de caractères universel normalisé.

En outre, le langage VoiceXML fournit un mécanisme permettant le contrôle précis des langues d'entrée et de sortie au travers de l'attribut xml:lang. Cette facilité offre :

• La possibilité de définir la langue d'entrée et de sortie surclassant la langue par défaut du processeur VoiceXML ;
• La possibilité de produire une sortie multilangue ;
• La possibilité d'interpréter une entrée dans une langue différente de la langue (ou des langues) de sortie.

Annexe H : L'accessibilité

Annexe I : La vie privée

Une version future de VoiceXML pourra définir des critères selon lesquels un processeur VoiceXML protègera la confidentialité des données personnelles.

Annexe J : Les changements survenus depuis VoiceXML 1.0

Voici un résumé des différences entre VoiceXML 2.0 et VoiceXML 1.0 [VOICEXML-1.0].

Les développeurs d'application VoiceXML 1.0 devraient faire particulièrement attention aux incompatibilités avec VoiceXML 1.0 mentionnées dans les sections Les éléments obsolètes et Les éléments modifiés de manière incompatible.

Les éléments nouveaux

• log pour définir un message de déboguage (5.3.13)
• metadata comme moyen de définir des informations de métadonnée en utilisant un schéma (6.2, 6.2.2)

Les éléments obsolètes

• dtmf remplacé par grammar avec mode="dtmf" (3.1.2)
• les éléments JSML <emp>, <div>, <pros> et <sayas> ont été remplacés par des éléments correspondants dans le langage de balisage de la synthèse vocale [SSML] (4.1.1)

Les éléments modifiés de manière incompatible

• Changé lang pour xml:lang dans vxml (1.5.1).
• Ajouté l'attribut obligatoire xmlns dans vxml (1.5.1)
• Remplacé l'attribut base par xml:base dans vxml (1.5.1)
• Changé et précisé que si une implémentation ne gère pas un objet particulier, elle suscite un événement error.unsupported.objectname. L'événement error.unsupported.format n'est pas suscité pour les types d'objet non reconnus (2.1.2.1, 2.3.5, 5.2.6)
• L'attribut type d'un élément field n'indique pas une classe say-as à utiliser à la prononciation de la valeur du champ. On doit utiliser un élément say-as explicite à la place (2.1.4, annexe P)
• Ajouté l'attribut accept aux éléments menu et choice (2.2.1, 2.2.2)
• Un événement error.badfetch (anciennement error.semantic) est suscité si l'attribut dtmf d'un élément menu est fixé à "true" et que des choix ont des séquences DTMF définies avec autre chose que "*", "#" ou "0" (2.2.1)
• Supprimé la gestion obligatoire de l'accès aux ressources intégrées telles que les grammaires et builtin est traité comme un système d'adresse URI propre à la plateforme pour l'accès aux ressources (2.3.1.2, annexe P)
• Ajouté l'attribut accept à l'élément option et modifié la description de la phrase de choix dans la génération d'une grammaire (2.3.1.3, 2.2.5)
• Supprimé l'attribut modal de l'élément subdialog (2.3.4)
• Supprimé l'attribut fetchaudio de l'élément object (2.3.5)
• Supprimé la capacité de l'élément value à jouer un enregistrement. Seul l'élément audio peut servir à jouer un enregistrement (2.3.6, 4.1.3, 4.1.4)
• Si une plateforme gère la reconnaissance vocale et l'enregistrement simultanément, alors l'entrée prononcée peut correspondre à une grammaire vocale active non locale. Si des grammaires vocales locales sont définies, elles sont traitées comme inactives (c.à.d. qu'elle sont ignorées), même si la plateforme gère la reconnaissance et l'enregistrement simultanés (2.3.6)
• Remplacé le schéma d'adresse URI phone par le schéma tel dans l'attribut dest (et destexpr) de l'élément transfer (2.3.7)
• Au cours d'un transfert de type pont, alors que l'interruption opère normalement, l'attribut bargeintype est fixé à "hotword", l'activation de grammaire est modale (seules les grammaires locales sont activées) et le son de chargement commence à jouer au point où l'appel sortant commence (2.3.7)
• Supprimé l'équivalence de notation entre l'élément filled dans un champ et un filled de niveau formulaire se déclenchant sur ce champ (2.4)
• Le traitement de l'attribut type dans l'élément grammar suit les pratiques standard du W3C. Si un type de média est renvoyé par le protocole, alors il fait autorité : il ne peut pas être surclassé par la plateforme VoiceXML, même s'il ne correspond pas au type de média réel de la ressource ou s'il ne peut pas être traité comme une grammaire. La valeur de l'attribut type peut servir à influencer la négociation de type de contenu (par exemple, dans HTTP 1.1) et il devient, seulement si aucun type de média n'est renvoyé par le protocole, le type de média autoritaire de la ressource (3.1.1.2, 3.1.1.4)
• Le contenu TTS des éléments choice, prompt, enumerate et audio remplacé par une définition dans le langage de balisage de la synthèse vocale [SSML])
• Dans un élément audio, si le fichier son ne peut être joué et que le contenu de l'élément est vide, aucun son n'est joué et aucune événement d'erreur n'est suscité (4.1.3)
• Supprimé les attribut class, mode et recsrc de l'élément value (4.1.4)
• Supprimé la variable de session normalisée session.uui. Ajouté les nouvelles variables de session génériques session.connection.protocol.name et session.connection.aai, lesquelles fournissent ces informations et plus (5.1.4)
• Remplacé la variable d'espace session.telephone par l'espace session.connection qui n'est pas propre à un protocole et qui est plus souple. Les noms d'erreur correspondants ont aussi changé (5.1.4)
• Le mécanisme selon lequel les objets ECMAScript, dans l'attribut namelist de l'élément submit, sont soumis, n'est pas défini pour l'instant mais réservé à une définition future. Les développeurs d'application peuvent soumettre explicitement les propriétés de l'objet au lieu de l'objet lui-même (5.3.8)
• Supprimé l'attribut caching (6.1)
• Ajouté les attributs maxage et maxstale (6.1)
• Supprimé "stream" comme valeur de la propriété fetchhint (6.1.1, 6.3.5)
• Supprimé caching des propriétés de chargement (6.3.5).
• Les grammaires de commande universelle propres à une plateforme sont optionnelles (6.3.6)

Les éléments modifiés

• Les plateformes peuvent faire la distinction entre un champ et le niveau de fiabilité d'un énoncé, c'est-à-dire que field$.confidence et application.lastresult$.confidence peuvent différer (2.3.1, 3.1.6.4, 5.1.5, 6.3.2 )
• Ajouté l'attribut srcexpr à l'élément subdialog (2.3.4)
• Ajouté la variable fictive maxtime à l'élément record (2.3.6)
• Ajouté l'attribut transferaudio à l'élément transfer ; ajouté "maxtimedisconnect" et "unknown" comme valeurs des transferts de type pont ; ajouté plusieurs événements de type error.connection (2.3.7)
• Ajouté les attributs aai et aaiexpr afin de permettre le passage de données avec l'élément transfer (2.3.7)
• Ajouté l'attribut dtmf à l'élément link (2.5).
• La forme XML de la spécification des grammaires de reconnaissance vocale du W3C [SRGS] doit être gérée dans l'élément grammar (3.1).
• Ajouté les attributs weight, mode, xml:lang, root et version à l'élément grammar (3.1).
• Ajouté l'attribut xml:lang à l'élément prompt (4.1).
• Ajouté l'attribut bargeintype à l'élément prompt, avec les valeurs "speech" et "hotword" (4.1).
• Ajouté l'attribut expr à l'élément audio (4.1.3)
• Ajouté la variable d'application application.lastresult$ décrivant le dernier résultat de reconnaissance, y compris n-best (5.1.5).
• Ajouté les attributs event, eventexpr, message et messageexpr aux éléments throw, choice, link et return (5.2.1).
• Ajouté la variable _event à l'élément catch (5.2.2).
• L'élément catch ne peut plus définir un attribut event dont la valeur est une chaîne vide (5.2.2, 5.2.4)
• Ajouté l'événement error.badfetch.http.<code de réponse> comme type d'erreur prédéfini (5.2.6)
• Ajouté l'événement error.badfetch.<protocole>.<code de réponse> comme type d'erreur prédéfini (5.2.6)
• Ajouté l'événement maxspeechtimeout (5.2.6)
• Ajouté l'événement error.unsupported.language comme type d'erreur prédéfini (5.2.6)
• Ajouté la gestion obligatoire de la valeur "multipart/form-data" pour l'attribut enctype de l'élément submit (5.3.8)
• L'élément script peut apparaître dans l'élément form (5.3.12)
• L'échec du chargement du son de chargement à partir de son adresse URI n'aboutit pas à la génération d'un événement error.badfetch : aucun son n'est joué pendant le chargement (6.1.1)
• Le protocole HTTP est obligatoire (6.1.4)
• Ajouté la propriété maxspeechtimeout (6.3.2)
• La gestion de la propriété completetimeout par la plateforme est optionnelle. Toutefois, une plateforme qui ne prendrait pas en charge cette propriété doit utiliser le maximum entre les valeurs des propriétés completetimeout et incompletetimeout comme valeur de la propriété incompletetimeout, et elle doit le documenter (6.3.2)
• Ajouté la propriété bargeintype (6.3.4)
• Ajouté fetchaudiodelay et fetchaudiominimum aux propriétés de chargement (6.3.5)
• Ajouté la propriété de session maxnbest (6.3.6)
• Ajouté la propriété universals (avec une valeur implicite de "none" (6.3.6).
• Ajouté des valeurs implicites aux attributs de chargement, ainsi que les attributs de chargement maxage et maxstale aux éléments choice, subdialog, object, link, grammar, audio, goto, submit et script

Les éclaircissements

• Des éclaircissements sur la façon dont les résultats de grammaire sont mappés au langage VoiceXML, à savoir : la notion d'élément d'entrée pour un élément de formulaire qui accepte une entrée ; seuls les éléments d'entrée peuvent être remplis en résultat d'une correspondance à une grammaire de niveau formulaire ; les correspondances aux grammaires de niveau champ ne peuvent pas remplir d'autres éléments d'entrée que le champ courant ; précision selon laquelle l'élément object peut se remplir et peut déclencher des actions filled ; ajout d'un principe de création pour la correspondance sémantique et les effets sur la variable lastresult$, les variables fictives et la phase de traitement dans l'algorithme FIA (1.2.4, 2.1.4, 2.1.5, 2.1.6.2.3, 2.2, 2.3.1, 2.3.1.3, 2.3.5, 2.3.6, 2.3.7.2, 2.4, 2.5, 3.1.1, 3.1.6, 3.1.6.1, 3.1.6.2, 3.1.6.3, 3.1.6.4, annexe C).
• Si aucune entrée, ou sortie, audio n'est disponible, alors un événement error.noresource doit être suscité (1.2.5, 5.2.6)
• Remplacé le terme confus élément de champ par élément de formulaire ou élément d'entrée, selon les cas (1.3.1, 2.1.6.2.2, 2.3, 2.3.3, 2.3.5, 3.1.6.1, 4.1.3, 5.1.1, 5.1.3, 6.3)
• Précisé que les grammaires de niveau application peuvent rester actives pour la durée de l'application, selon les règles d'activation des grammaires dans le chapitre 3.1.4 (1.3.3)
• Définitions des documents racine et terminaux, et des transitions entre eux (1.5.2).
• L'appel du document racine d'application et de ses grammaires (1.5.2).
• Lorsqu'un sous-dialogue est invoqué avec seulement un identificateur de fragment, les pages racines et terminales restent inchangées, et elles servent à initialiser les contextes de la racine et des terminaux (1.5.2)
• Dans une transition racine à racine, le contexte d'initialisation racine est déterminé par la politique de mise en cache, même si l'application courante et celle cible ont le même nom (1.5.2)
• Éclaircissement des transitions par adresse URI, notamment les identificateurs de fragment, en relation avec le document RFC2396 (1.5.2, 2.3.4, 5.3.7, 5.3.8, 6.1.1)
• Un éclaircissement sur la façon dont les documents racines sont traités dans les applications multi-documents, et les avantages à utiliser des documents racines (1.5.2)
• Un événement error.badfetch est suscité lorsqu'un document appelle un document racine inexistant et qu'un événement error.semantic est suscité s'il appelle un document racine appelant à son tour un document racine (1.5.2)
• Un élément subdialog, transférant le contrôle à un autre élément subdialog et un autre dialogue, via l'élément goto (1.5.3).
• Ajouté une section décrivant l'état de traitement final quand il n'y a plus de connexion entre l'interpréteur et l'utilisateur. Supprimé la description du traitement final dans l'élément catch (1.5.4, 5.2.2)
• La portée définie sur les grammaires de formulaire individuel est prioritaire sur la portée de grammaire implicite dans un élément form (2.1).
• Le comportement lors de l'exécution des instances des éléments object non reconnus (2.1.2.1, 2.3.5).
• Dans un élément object, lorsqu'une plateforme ne gère pas un objet particulier, un événement error.unsupported.objectname est suscité, le terme objectname est une chaîne fixe qui ne se remplace pas par le nom de l'objet particulier en question. En général, les composants substituables d'un événement sont donnés en italiques (par exemple, objet dans error.unsupported.objet) (2.1.2.1, 2.3.5, 5.2.6 )
• Si une plateforme ne gère pas un élément object particulier, alors un événement error.unsupported.objectname est suscité (2.1.2)
• Les multiples éléments prompt dans un élément field n'ont pas besoin d'un attribut count. La ou les invites dans un champ sont mises en file d'attente en vue de leur lecture, selon l'algorithme de sélection des invites décrit dans le chapitre 4.1.6 (2.1.4)
• L'effet de la déclaration <goto nextitem> sur un élément de formulaire (2.1.5).
• Aucune variable ni aucune condition ni aucun compteur ne sont réinitialisés dans l'utilisation de <goto nextitem> (2.1.5).
• Précisé que les dialogues à initiative mixte nécessitaient des formulaires avec des grammaires de niveau formulaire, et que plusieurs styles de création existent pour l'initiative mixte, dont utiliser l'élément initial et des attributs cond sur des éléments field (2.1.5)
• La déclaration <goto nextitem> force un transfert immédiat vers l'élément de formulaire indiqué, même si un quelconque attribut cond sur l'élément de formulaire s'évaluait à "false" (2.1.5.1)
• Le comportement des éléments transfer, subdialog et object avec la lecture d'un son dans la phase de collecte (2.1.6).
• La sélection d'un gestionnaire d'événement dans la phase de traitement de l'algorithme FIA et l'élément filled (2.1.6.2).
• Précisé que, lorsque des erreurs survenues au cours des phases de sélection ou de collecte de l'algorithme FIA aboutissent à la génération d'un événement, l'algorithme FIA se place directement en phase de traitement (2.1.6.2, 2.1.6.2.1, 2.1.6.2.3)
• Lorsqu'une erreur est suscitée dans un contenu exécutable, aucun des éléments exécutables suivants du bloc procédural n'est exécuté et, si aucun transfert explicite du contrôle n'a lieu, il se produit un exit implicite (2.1.6.2.1, 5.3)
• Énuméré les éléments d'un contexte exécutable qui terminent une exécution (2.1.6.2.3).
• L'élément reprompt ne termine pas l'algorithme FIA (2.1.6.2.3).
• Précisé que la valeur par défaut de l'attribut dtmf de l'élément menu est "false" (2.2.1)
• Précisé la définition et le comportement des attributs et des sous-éléments s'excluant mutuellement( 2.2.2, 2.3.4, 2.3.7, 2.5, 3.1.1.4, 4.1.3, 5.2.1, 5.3.7, 5.3.8, 5.3.9, 5.3.10, 5.3.12, 6.4)
• Dans un élément menu, c'est une erreur sémantique si on a dtmf="true" et que des éléments choice ont défini explicitement des valeurs autres que "0", "*" et "#" pour leur attribut dtmf. S'il y a plus de 9 éléments choice n'ayant pas défini d'attribut dtmf, alors aucun attribut dtmf n'aura d'assignation automatique (aucune entrée DTMF ne peut correspondre à un choix), mais aucune erreur n'est générée (2.2.3)
• L'utilisation de l'élément enumerate (2.2.4, 2.3.1)
• L'élément grammar surclasse les grammaires générées automatiquement dans l'élément choice (2.2.2).
• L'attribut expr de l'élément choice est évalué à l'adresse URI vers laquelle effectuer une transition (2.2.2).
• Le gestionnaire d'événement d'un élément choice, sans contrôle de la transition, provoque la réexécution du menu (2.2.2).
• Les séquences DTMF indiquées par les attributs dtmf des éléments choice, option et link sont équivalentes à des grammaires DTMF simples, dans lesquelles les propriétés DTMF s'appliquent à la reconnaissance de la séquence. Toutefois, contrairement aux grammaires, les blancs sont optionnels dans les séquences DTMF (2.2.2, 2.3.1.3, 2.5)
• Précisé que les grammaires vocales et DTMF, mais pas les fragments de grammaire, sont permises dans les éléments choice (2.2.2)
• Pour l'élément enumerate, si aucune séquence DTMF n'est assignée à l'élément choice, ou si un élément grammar est défini dans l'élément choice, alors la variable _dtmf reçoit la valeur ECMAScript "undefined" (2.2.4)
• Pour l'élément enumerate, la valeur de la variable _dtmf est une représentation normalisée de la séquence DTMF, c'est-à-dire, une seule espace entre les atomes DTMF (2.2.4)
• Définition de la génération de grammaire "approximate" dans les éléments menu et choice (2.2.5)
• Un élément de formulaire est exécuté s'il n'est pas rempli et que son attribut cond n'est pas défini, ou s'évalue à "true" (2.3, 2.3.1)
• Réorganisé la présentation des éléments de formulaire pour préciser quelles caractéristiques s'appliquent à tel élément de formulaire. Indiqué également que l'élément de formulaire initial peut contenir des éléments property et catch (2.3)
• L'évaluation d'une expression cond a lieu après une conversion en valeur booléenne. Cela concerne l'attribut cond dans les éléments de formulaire field, block, initial, subdialog, object, record et transfer (2.3), prompt (4.1) et catch (5.2.2, 5.2.4)
• Précisé que les variables fictives sont réinscriptibles et susceptibles d'être modifiées par l'application. Changé la variable application.lastresult$, afin qu'elle soit également réinscriptible et puisse être modifiée par l'application (2.3, 5.1.5 )
• L'assignation de la variable de champ quand l'attribut dtmf est défini (2.3.1).
• Le nom d'un champ doit être unique parmi les noms des éléments de formulaire dont son formulaire. Les variables déclarées dans un élément script le sont dans la portée de l'élément contenant cet élément script (2.3.1, 5.3.12)
• Les noms des variable d'élément de formulaire doivent respecter les conventions de nommage des variables ECMAScript (2.3.1, 5.1).
• Si un type intégré défini d'élément field n'est pas géré par la plateforme, un événement error.unsupported.builtin est suscité. Si une plateforme gère les types intégrés, alors elle doit gérer tous les types intégrés dans le langage en question (2.3.1, 5.2.6, annexe P)
• L'utilisation des grammaires vocales et DTMF avec le système d'adresse URI "builtin: (2.3.1.2).
• La chaîne renvoyée pour une entrée DTMF, quand aucun attribut valuestring ni données PCDATA ne sont définis dans un élément option (2.3.1.3).
• On peut utiliser simultanément les éléments option et grammar pour définir les grammaires d'un élément field (2.3.1.3).
• Dans un élément option, si ni contenu de type CDATA ni séquence DTMF ne sont définis, alors l'attribut value a la valeur implicite "undefined", et la variable d'élément de formulaire du champ n'est pas remplie (2.3.1.3)
• Dans un élément option, l'attribut dtmf est optionnel. Si aucune valeur n'est définie pour l'attribut dtmf, alors aucune séquence DTMF n'est associée à l'option lequel, de ce fait, ne peut pas être sélectionné par une entrée DTMF (2.3.1.3)
• Les règles de portée normales des grammaires s'appliquent lors de la visite d'un élément initial : en particulier, aucune grammaire d'élément d'entrée n'est active (2.3.3)
• Précisé qu'un formulaire peut admettre plusieurs éléments initial, et comment ils sont sélectionnés pour l'exécution (2.3.3, annexe C)
• La portée des variables dans un élément subdialog (2.3.4).
• Le contexte d'un élément subdialog est indépendant du contexte qui l'appelle (les instances de variable ne sont pas partagées), mais son contexte suit les règles de portée normales des grammaires, des événements et des variables (2.3.4).
• Dans un élément subdialog, utiliser l'attribut expr pour fixer une variable si aucun élément param correspondant n'est défini (2.3.4).
• Précisé la description du contexte d'exécution du sous-dialogue (2.3.4)
• Précision sur la façon dont l'élément return, dans un élément subdialog, passe des données à son dialogue appelant (2.3.4, 5.3.10)
• Les variables dans les sous-dialogues sont associées aux paramètres par leur nom, et dans l'ordre du document. Les valeurs des paramètres sont évaluées dans le contexte de l'élément param (2.3.4)
• Un événement error.badfetch est suscité lors d'une tentative de transition invalide dans les éléments subdialog, goto et submit. La portée dans laquelle est gérée une erreur au cours d'une transition dépend de la plateforme (2.3.4, 5.3.7, 5.3.8)
• Précisé qu'un subdialog sans élément return continue jusqu'à ce qu'il rencontre un élément exit ou qu'il ne reste aucun élément de formulaire susceptible d'une sélection par l'algorithme FIA, ce qui équivaut à un élément exit (2.3.4)
• Précisé qu'une chaîne de requête autonome n'est pas une adresse URI valide : par conséquent, ces chaînes n'exigent aucune gestion particulière dans les adresses URI intermédiaires définies dans les éléments subdialog et goto (2.3.4, 5.3.7, 6.1.1)
• Si l'attribut namelist, dans les éléments subdialog, submit, clear, exit ou return, appellent une variable non déclarée, alors un événement error.semantic est suscité ( 2.3.4, 5.3.3, 5.3.8, 5.3.9, 5.3.10 )
• Dans un élément subdialog, les paramètres doivent se déclarer en tant qu'éléments var dans le formulaire exécuté comme sous dialogue, sinon un événement error.semantic sera suscité (2.3.4, 6.4)
• Précisé que l'élément object est lui-même responsable de déterminer si le nom ou la valeur de paramètre qu'il reçoit est invalide. Le cas échéant, une erreur est suscitée : il peut s'agir d'une erreur standard ou d'une erreur propre à l'objet (2.3.5)
• L'utilisateur qui raccroche au cours d'un enregistrement termine l'enregistrement normalement. Les données enregistrées avant le raccrochage peuvent être renvoyées au serveur (2.3.6).
• L'interprétation des grammaires dans l'élément record (2.3.6).
• La variable de champ dans un élément record est une référence à un son enregistré. Pour la soumission des données enregistrées à un serveur, l'attribut enctype de l'élément submit devrait avoir la valeur "multipart/form-data" (2.3.6, 5.3.8).
• Précision de comportement lorsque l'attribut dtmfterm de l'élément record a la valeur "false" à la réception de l'entrée DTMF (2.3.6)
• Précision sur le moment où l'enregistrement commence et sur le comportement quand il se termine, avant qu'une quelconque donnée audio ne soit collectée (2.3.6)
• Précisé que la façon dont la variable de l'élément record est mise en œuvre peut varier entre les plateformes, bien que toutes les plateformes doivent gérer le comportement qu'elle définit dans les éléments audio et submit (2.3.6)
• Précisé que les valeurs par défaut des attributs finalsilence et maxtime de l'élément record sont propres à la plateforme (2.3.6)
• Pendant l'exécution de l'élément record, si aucun son n'est collecté avant que l'utilisateur ait terminé l'enregistrement par une entrée DTMF correspondant à un grammaire DTMF locale (ou si l'attribut dtmfterm a la valeur "true, alors la variable de l'élément record n'est pas remplie (les variables fictives ne sont donc pas fixées), et l'algorithme FIA s'applique normalement, sans génération d'un événement noinput. Toutefois, dans cette situation, les informations concernant l'entrée peuvent être disponibles via la variable application.lastresult$ comme décrit dans le chapitre 5.1.5. (2.3.6)
• Dans l'élément record, l'attribut dtmfterm a priorité sur les grammaires DTMF locales définies (2.3.6)
• Dans l'élément record, aucun son ne peut être collecté si l'entrée vocale, ou DTMF, est reçue pendant la lecture d'une invite ou avant que l'intervalle timeout n'expire (2.3.6)
• La terminaison de l'élément transfer, par une parole ou une tonalité DTMF, renvoi le statut near_end_disconnect (2.3.7).
• La valeur de l'attribut dest sur l'élément transfer (2.3.7).
• La variable d'élément de formulaire de l'élément transfer vaut "undefined" pour un transfert de type aveugle (2.3.7).
• Révision de l'élément transfer, comprenant : les événements d'erreur quand la plateforme est incapable de manipuler les attributs dest/destexpr, une précision selon laquelle la plateforme est déconnectée immédiatement quand un transfert de type aveugle se produit, une définition des événements à générer si la plateforme ne peut réaliser un transfert de type pont ou de type aveugle, une précision selon laquelle le statut de connexion n'est pas disponible pour un transfert de type aveugle (bien que quelques conditions d'erreur puissent être signalées), l'attribut transferaudio est ignoré pour un transfert de type aveugle, une précision sur la lecture audio avant et pendant un transfert de type pont, y compris le cas où le son de chargement se termine avant l'établissement de la connexionsituation, et le son en file d'attente qui est purgé avant le commencement du transfert, une précision sur les temporisations pour l'écoute d'une entrée et la lecture du son, ajouté les variables fictives nom$.inputmode et nom$.utterance, précisé que la gestion par la plateforme de l'écoute d'une entrée pendant un transfert est optionnel (2.3.7, 5.2.6)
• La valeur de l'attribut bargeintype sur un transfer de type pont est fixée à "hotword" pour la durée de l'appel sortant (2.3.7)
• Les plateformes qui gèrent soit le transfert de type aveugle soit celui de type pont peuvent gérer les modes d'entrée interruptifs vocaux, DTMF, ou les deux, pendant le transfert d'appel pour abandonner la connexion distante. Dans le transfert de type aveugle comme celui de type pont, si le transfert n'a pas été terminé par une correspondance de grammaire, la variable fictive nom$.inputmode n'est pas définie. On ne peut annuler les tentatives de transfert de type aveugle que jusqu'au point où l'appel sortant commence. Dans un transfert de type aveugle, le format des conditions d'erreur propres à la plateforme devrait suivre les conventions de nommage des autres valeurs de variable d'élément de formulaire de transfert. L'appelant peut annuler une tentative de transfert de type aveugle, avant que l'appel sortant ne commence, en l'interrompant avec une commande vocale, ou DTMF, correspondant à une grammaire active, pendant la lecture de n'importe quel fichier son dans la file d'attente : auquel cas la variable d'élément de formulaire est fixée, ses variables fictives sont fixées, ainsi que la variable application.lastresult$. Si l'appelant se déconnecte en raccrochant au cours d'une tentative de transfert de type aveugle, avant que la connexion avec l'appelé ne commence, un événement connection.disconnect.hangup sera suscité, et l'exécution du dialogue se portera vers un gestionnaire de l'événement hangup. La variable d'élément de formulaire et donc les variables fictives ne seront pas fixées. Si l'appelant annule la tentative de transfert de type aveugle via une commande vocale, ou DTMF, avant que l'appel sortant ne commence (pendant la lecture d'un fichier son en file d'attente), la variable d'élément de formulaire est fixée à "near_end_disconnect". Dans un transfert de type pont, l'appelant peut annuler la tentative de transfert, avant que l'appel sortant ne commence, en l'interrompant avec une commande vocale, ou DTMF, correspondant à une grammaire active pendant la lecture de n'importe quel fichier son en file d'attente (2.3.7)
• Précisé que la variable de l'élément transfer et les variables fictives ne sont pas fixées si l'appelant raccroche pendant un transfert d'appel ou une tentative de transfert d'appel. Si l'appel est terminé par l'appelant par une commande vocale, ou DTMF, avant une réponse, la variable fictive duration est fixée à "0 (2.3.7.2.2)
• Précisé que la variable fictive utterance de l'élément transfer est fixée à la valeur du résultat DTMF, si le transfert a été terminé par une entrée DTMF (2.3.7.2.2)
• Répondu à la situation selon laquelle, dans un transfert de type pont, l'appelant force l'appelé à se déconnecter via une commande vocale, ou DTMF, avant que la connexion ne soit établie (2.3.7.2.2)
• Dans un élément transfer, la variable fictive nom$.inputmode n'est pas définie si le transfert n'a pas été terminé par une correspondance de grammaire (2.3.7.2.2)
• Dans la rencontre d'un document contenant un élément filled définissant soit un attribut mode, soit un attribut namelist comme enfant d'un élément d'entrée, alors un événement error.badfetch est suscité par la plateforme. En outre, un événement error.badfetch est suscité lorsque le document contient un élément filled avec un attribut namelist référençant une variable d'élément de commande (2.4)
• Les éléments link ont zéro grammaire, ou plus (2.5).
• Ls événements suscité par un élément link sont gérés par le mieux qualifié des éléments catch dans la portée active (2.5).
• Un élément link ne peut être un enfant que des éléments de formulaire fiel ou initial (2.5)
• Précisé qu'un attribut scope sur l'élément contenant un élément link n'a aucun effet sur la portée des grammaires de cet élément link (2.5)
• Précisé que, dans un élément link, toutes les adresses URI dans son contenu (par exemple, celles d'éléments grammar) s'évaluent/se résolvent là où l'élément link est défini, alors que toutes les adresses URI et les expressions ECMAScript dans ses attributs s'évaluent/se résolvent dans la portée du dialogue et le contexte actifs (2.5)
• Dans un élément link, les grammaires ne sont pas autorisées à définir de portée comme décrit dans le chapitre 3.1.3 (2.5)
• Si l'exécution a lieu dans un élément de formulaire modal, alors les grammaires des éléments link, au niveau application, ne sont pas actives (2.5)
• L'attribut xml:lang dans un élément grammar n'exige pas une gestion multilangue de la plateforme (3.1)
• La langue non gérée d'une grammaire aboutit à la génération d'un événement error.unsupported.language (3.1.1)
• Une langue non gérée peut s'indiquer dans la variable message d'un élément throw (3.1.1).
• Un type number résulte en une chaîne laquelle sera automatiquement convertie en un nombre dans une expression numérique par le langage ECMAScript ; la chaîne ne doit pas utiliser de zéro en tête (3.1.1)
• Précisé que l'élément SRGS grammar est augmenté dans VoiceXML 2.0 afin de permettre des données de type PCDATA pour les formats des grammaires directes, parallèlement au format XML de SRGS ( 3.1.1, 3.1.1.4 )
• Les grammaires implicites (telles que les options) ne gèrent pas les poids (3.1.1.3).
• L'attribut type dans un élément grammar a priorité sur les autres sources possibles de type de média. S'il est défini et qu'il entre en conflit avec le type de la grammaire, alors une erreur est suscitée (3.1.1.2, 3.1.1.4)
• Précisé l'utilisation et l'interprétation des attributs de l'élément grammar hérités de la spécification SRGS (version, xml:lang, mode, root, tag-format, xml:base). Les grammaires SRGS directes de format XML suivent le comportement défini dans la spécification SRGS. En ce qui concerne les grammaires SRGS de type ABNF, ainsi que les grammaires SRGS externes de type ABNF et de type XML, la plateforme doit ignorer ces attributs. Pour tous les autres types de grammaire, l'utilisation et l'interprétation de ces attributs dépendent de la plateforme (3.1.1.4)
• Précisé que la règle racine dans les grammaires SRGS n'a pas besoin d'être une règle publique (3.1.1.4)
• Les formes d'appel de règle, définies par la spécification SRGS, et non gérées dans VoiceXML 2.0, ne s'appliquent qu'aux appels de grammaires externes utilisant l'attribut src (3.1.1.4)
• Précisé la distinction entre les grammaires de niveau formulaire et celles de niveau champ (3.1.6, 3.1.6.1, 3.1.6.2 )
• L'attribut slot peut sélectionner des propriétés à des niveaux d'imbrication arbitraires en utilisant une liste séparée par des points ; supprimé le passage suggérant que les expressions d'indexation de tableau (par exemple,pizza.toppings[3]) étaient gérées (3.1.6.1)
• Précisé qu'une correspondance à des grammaires de niveau formulaire peut surclasser les valeurs existantes dans les éléments d'entrée, et que le traitement filled de ces éléments a lieu selon les descriptions du chapitre 2.4 et de l'annexe C (3.1.6.1)
• Aligné la description la description des grammaires DTMF sur celle des grammaires vocales : les grammaires DTMF peuvent renvoyer un ensemble de couples attribut-valeur comme une valeur de chaîne (3.1.2)
• Si un document contient une grammaire définissant un portée et que cette grammaire est contenu dans un élément field, un élément link ou dans un élément choice d'un menu, alors un événement error.badfetch est suscité (3.1.3)
• Si aucune grammaire n'est active quand une entrée est attendue dans un élément form ou menu, un événement error.semantic est suscité (3.1.4)
• La propriété inputmodes n'affecte pas l'activation des grammaires (3.1.4, 6.3.6)
• Si l'entrée correspond à plusieurs grammaires actives de même priorité, alors la première dans l'ordre du document sera prioritaire (3.1.4)
• Les travaux se poursuivent en ce qui concerne les attaches sémantiques dans un élément grammar (3.1.5)
• Les variables des éléments d'entrée peuvent être fixées par les résultats sémantiques d'autres éléments d'entrée (3.1.6)
• Les valeurs par défaut des attributs bargein et bargeintype de l'élément prompt sont déterminés par les propriétés bargein et bargeintype (4.1)
• Précisé qu'un indicateur de temps est un nombre non négatif qui doit être suivi par ms ou s. Précisé que les attributs suivants admettent des indicateurs de temps en tant que valeurs : timeout avec l'élément prompt, maxtime (la valeur implicite est désormais "0s") et connecttimeout avec l'élément transfer, maxtime et finalsilence avec l'élément record. Précisé que les propriétés suivantes ont des valeurs d'indicateur de temps : fetchtimeout, completetimeout, incompletetimeout, maxspeechtimeout, interdigittimeout, termtimeout, timeout, fetchaudiodelay, fetchaudiominimum, fetchtimeout ( 4.1, 2.3.6, 2.3.7, 6.1.1, 6.3)
• L'attribut xml:lang dans un élément prompt ne nécessite pas une gestion multilingue de la part de la plateforme (4.1.1)
• Une langue de synthèse non gérée aboutit à la génération d'un événement error.unsupported.language (4.1.1).
• Un élément prompt englobant est nécessaire si le texte contient des balises de synthèse vocale (4.1.2).
• Quand un contenu d'invite est défini sans élément prompt explicite, alors les attributs d'invite sont définis comme indiqué dans le tableau du chapitre 4.1 (4.1.2)
• Le contenu de remplacement dans l'élément audio (4.1.3).
• Lorsque l'attribut expr d'un élément audio est évalué à la valeur ECMAScript "undefined", le contenu de l'élément est ignoré. S'il est évalué à une adresse URI invalide, ou si le format n'est pas géré, etc., alors la stratégie de repli est invoquée (4.1.3)
• Que la plateforme envoie en continu le son d'un élément audio constitue une optimisation (4.1.3)
• Précisé que l'attribut expr d'un élément audio est une expression ECMAScript qui appelle un son enregistré précédemment dans un élément record, ou qui s'évalue en l'adresse URI d'une source audio à charger (4.1.3)
• Un élément value autonome est légale hors d'un élément prompt (4.1.4).
• Simplifié l'évaluation de l'attribut expr dans un élément audio de façon à ce qu'il ne soit pas traité d'une manière particulière : il s'agit de données de type CDATA dans lesquelles les caractères spéciaux pour XML n'ont pas besoin d'être échappés. Il n'est pas traité comme un document SSML ou un fragment de document (4.1.4)
• Une entrée DTMF mise en tampon est effacée lorsque l'attribut bargein de l'élément prompt a la valeur "false" (4.1.5).
• Précisé le comportement selon lequel une interruption se produit pendant une succession d'invites (4.1.5)
• Précisé que, lorsque l'attribut bargein d'un élément prompt a la valeur "false, aucune entrée n'est mise en tampon tandis que l'invite joue, toute entrée DTMF déjà mise en tampon est effacée (4.1.5)
• L'attribut bargeintype d'un élément prompt s'applique à une entrée DTMF comme à une entrée vocale (4.1.5.1)
• Quand la valeur de l'attribut bargeintype est "speech", l'invite est arrêtée, sans tenir compte des grammaires actives (4.1.5.1)
• Quand la valeur de l'attribut bargeintype est "hotword, l'entrée qui ne correspond pas à une grammaire est ignorée, même pendant la période indiquée par l'attribut timeout (4.1.5.1)
• Les compteurs d'invites sont également maintenus pour les éléments initial dans un formulaire (4.1.6)
• Dans la sélection d'une invite, dès lors que le système sélectionne un élément d'entrée donné dans la phase de sélection de l'algorithme FIA et que l'algorithme FIA effectue une sélection et une mise en file d'attente normales des invites, le compteur d'invites associé à l'élément d'entrée est incrémenté (4.1.6)
• Précisé que chaque élément prompt a sa propre valeur d'expiration et que l'attribut timeout d'un élément prompt a pour valeur implicite la valeur de la propriété timeout au moment où l'invite est mise en file d'attente (4.1.7)
• Les relations entre la mise en file d'attente des invites et la collecte des entrées (4.1.8).
• Les événements asynchrones, non apparentés à l'exécution d'une transition (par exemple, un événement disconnect), sont mis en tampon jusqu'à un état d'attente avant d'être générés (4.1.8)
• Précisé les relations entre les états de l'interpréteur et l'algorithme FIA, et que l'activation des grammaires et l'attente d'une entrée se produisent simultanément à la lecture des invites (4.1.8)
• Précisé que, lorsque l'attribut bargein d'un élément prompt a la valeur "false", l'entrée n'est pas collectée, et les tonalités DTMF mises en tampon dans l'état de transition sont effacées comme décrit dans le chapitre 4.1.5 (4.1.8)
• Les plateformes peuvent varier dans la mesure où elles écartent ou non une entrée DTMF non correspondante lorsqu'une grammaire ASR correspond avec une entrée (4.1.8)
• Les variables VoiceXML et ECMAScript font partie du même espace de variables : les variables déclarées dans ECMAScript peuvent servir directement dans VoiceXML (5.1).
• Les noms des variables VoiceXML, y compris les noms des champs, doivent suivre les règles de nommage ECMAScript ; les déclarations des noms de variable ne peuvent pas contenir de point : le nom de champ a.b est illégal (5.1).
• Les variables VoiceXML et la portée des variables suivent les chaînes de portée ECMAScript. Par conséquent, l'appel à une variable ECMAScript non déclarée génère un événement error.semantic (5.1.1, 5.1.2)
• La portée des variables (5.1.2).
• Précisé la portée des variables, dans l'application et dans le document, dans les documents racines d'application (5.1.2)
• La portée du dialogue contient les variables des éléments de formulaire, non les variables définies dans chaque élément de formulaire (5.1.2)
• Seuls certains opérateurs cond nécessitent un échappement (5.1.3).
• Précisé qu'un document ayant une variable x, mais sans racine d'application définie, alors la variable peut être appelée par application.x et document.x (5.1.3)
• Précisé que application.lastresult$ est un tableau ECMAScript (5.1.5)
• Précision sur la persistence de la variable d'application lastresult (5.1.5)
• Les interprétations dans lastresult sont d'abord rangées selon la fiabilité, puis selon la priorité des portées des grammaires (5.1.5, 2.3.1, 3.1.4)
• Quand une grammaire DTMF a une correspondance, la variable interpretation de application.lastresult contient la chaîne numérique qui correspond (5.1.5)
• Après un nomatch, le tableau application.lastresult$ est bien fixé mais les valeurs dépendent de la plateforme (5.1.5)
• L'évaluation des adresse URI relatives par rapport au document actif (5.2).
• Précisé que les éléments catch se servent de la propriété la plus intérieure de l'élément d'où l'événement est originaire, et non où l'élément catch est défini (5.2)
• Le langage VoiceXML ne définit généralement pas le moment où les événements sont générés (5.2.1).
• Les compteurs d'événements associés aux élément catch sont incrémentés lorsqu'un événement se produit avec le même nom correspondant, entier ou préfixe ; cela affecte la sélection du gestionnaire de capture avec le compte correct dans le chapitre 5.2.4 (5.2.2)
• La définition des attributs event et count de l'élément catch (5.2.2).
• Aucune limitation inhérente sur l'élément catch, par exemple, dans le cas d'un raccrochage de l'utilisateur (5.2.2).
• La valeur de l'attribut event d'un élément catch peut être la chaîne ".", signifiant que tous les événements sont susceptibles d'être capturés (5.2.2).
• Un élément catch sans attribut event défini équivaut à l'un déclarant event="." (5.2.2, 5.2.4)
• Précisé les moments où les compteurs d'événements des formulaires sont incrémentés et réinitialisés (5.2.2)
• L'élément catch s'applique aux éléments de formulaire, sauf à l'élément block (5.2.2)
• L'héritage de la capture comme par copie (5.2, 5.2.4).
• L'algorithme de sélection de l'élément catch (5.2.4).
• Défini la correspondance de préfixe comme un correspondance d'atome plutôt qu'une correspondance de chaîne (5.2.4).
• Dans l'élément catch, un attribut event ayant pour valeur une chaîne vide est invalide d'un point de vue syntaxique. Pour capturer tous les événements, on peut omettre l'attribut event, ou lui donner la valeur "." pour filtrer tous les événements par préfixe (5.2.4)
• Le type d'erreur prédéfini error.badfetch (5.2.6)
• Un événement error.badfetch est suscité tant que le document n'est pas prêt pour l'exécution. Que l'initialisation des variables fasse partie de l'exécution, ou non, dépend de la plateforme (5.2.6)
• Précision sur les situations dans lesquelles un événement error.badfetch est suscité. Un navigateur conforme peut également susciter des événements dont le nom prolonge celui d'événements prédéfinis (5.2.6)
• Les types d'événement propres à l'application et propres à la plateforme devraient suivre la convention de nom de domaine Internet inversée pour éviter les conflits de nommage (5.2.6)
• Le protocole HTTPS n'est pas le même protocole que HTTP (5.2.6)
• Les erreurs déclenchées dans le premier document d'une session, et celles déclenchées avant d'entrer dans l'algorithme FIA dans les documents chargés consécutivement sont gérées d'une façon propre à la plateforme (5.2.6)
• Supprimé la division par 0 comme erreur à l'exécution, laquelle résulte dans la génération d'un événement error.semantic, le langage ECMAScript ne signalant pas d'erreur (5.2.6)
• Précisé que l'événement error.noauthorization est suscité en plus de circonstances que simplement un échec d'authentification à la connexion (5.2.6)
• Précisé que l'événement error.unsupport.élément n'est généré que pour les documents VoiceXML 2.0 (5.2.6)
• L'attribut name d'un élément var défini une variable sans préfixe de portée. S'il définit une variable avec un préfixe de portée, alors un événement error.semantic est suscité (5.3.1)
• Précisé qu'un événement error.semantic est suscité en cas de tentative d'assignation d'une variable non déclarée. Les propriétés des objets ECMAScript objects, par exemple, obj.foo, peuvent être assignées directement : les tentatives pour les déclarer aboutissent à la génération d'un événement error.semantic (5.3.2)
• L'attribut name d'un élément assign doit appeler une variable déjà déclarée, sinon un événement error.semantic sera suscité. Par défaut, la portée dans laquelle la variable se résoud est la plus proche portée englobante de l'élément actuellement actif. Pour lever les ambiguïtés, le nom de la variable peut être préfixé par un nom de portée (5.3.2)
• L'attribut namelist d'un élément clear peut définir des variables autres que les variables d'élément de formulaire qui doivent être réinitialisées (5.3.3)
• Les appels de variable dans l'attribut namelist de l'élément clear se résolvent par rapport à la portée courante, selon le chapitre 5.1.3 (5.3.3)
• L'effet d'un élément reprompt dans les éléments de capture (5.3.6)
• Le comportement d'un élément reprompt lorsqu'il est contenu dans un élément catch ayant un élément goto final (5.3.6)
• L'algorithme FIA effectue une mise en file d'attente normale des invites après l'exécution des éléments de capture lorsqu'ils se terminent par un élément submit ou return, tout comme un élément goto (5.3.6, annexe C)
• Précisé qu'un élément reprompt n'a aucun effet en dehors d'un élément catch (5.3.6)
• L'effet d'une adresse URI dans un élément goto sur les variables de document (5.3.7)
• Précisé, pour les éléments goto, que si des erreurs se produisent au cours de la transition à un élément de formulaire, alors l'événement est géré dans la portée du dialogue (5.3.7)
• Lorsque l'attribut nextitem, ou expritem, dans un élément goto appelle un élément de formulaire inexistant, alors un événement error.badfetch est suscité (5.3.7)
• Les variables déclarées dans les langages VoiceXML ou ECMAScript peuvent être soumises (5.3.8).
• Précisé quelques circonstances dans lesquelles un élément submit peut être satisfait par des caches intermédiaires (5.3.8)
• Dans l'élément submit, l'attribut enctype n'est pertinent que si l'attribut method est fixé à "post" (5.3.8)
• Un élément exit ne génère pas d'événement exit (5.3.9)
• La valeur de l'attribut expr d'un élément exit est une expression ECMAScript (5.3.9)
• L'exécution d'un élément disconnect incite l'interpréteur (a) à entrer dans l'état de traitement final et (b) à purger la file d'attente des invites (5.3.11)
• Aucun attribut type sur l'élément script (5.3.12).
• L'élément script est évalué en même temps que les éléments var et les variables d'élément de formulaire dans un élément form (5.3.12)
• La définition de l'attribut charset dans l'élément script (5.3.12)
• La gestion des éléments log dépend de la plateforme (5.3.13)
• Les attributs label et expr de l'élément log sont optionnels (5.3.13)
• Revu le préchargement (6.1)
• L'effet de l'attribut fetchhint (6.1.1)
• La sélection de la politique de mise en cache (6.1.2)
• La mise en cache suit les règles d'exactitude du protocole HTTP 1.1 (6.1.2)
• Précisé qu'il n'existe pas de mécanisme de balisage pour contrôler la mise en cache des documents racines d'application (6.1.2.1)
• Précisé que le premier type d'élément meta est exprimé par les attributs name et content, et le second type par les attributs http-equiv et content (6.2.1)
• Lorsque des valeurs différentes sont définies au même niveau pour un élément property, alors le dernier dans l'ordre du document s'applique (6.3)
• On peut fixer les propriétés dans les éléments d'entrée field, mais pas dans les éléments d'entrée de commande (6.3)
• Précisé que, si une plateforme détecte une propriété ayant une valeur illégale, alors elle devrait générer un événement error.semantic (6.3)
• Le format des propriétés propres à une plateforme (6.3.1)
• Les définitions des propriétés des logiciels de reconnaissance vocale completetimeout et incompletetimeout (6.3.2)
• Les grammaires de commandes universelles sont toujours actives sauf dans le cas d'éléments d'entrée modaux (6.3.6)
• Les valeurs des paramètres passés à l'élément subdialog sont toujours des données (6.4)
• La définition des valeurs de désignation de temps (6.5)
• Précisé que le format des nombres est celui employé dans la spécification CSS2, et que la valeur des propriétés ASR confidencelevel, sensitivity et speedvsaccuracy sont dans ce format (6.5, 6.3.2)
• Restreint les noms des champs, l'attribut name de l'élément var et l'attribut nextitem de l'élément goto au type NMTOKEN ; augmenté l'attribut name de l'élément assign comme de type NMTOKEN mais autorisé le caractère $, pour les assignations des variables fictives ; restreint l'attribut namelist de l'élément filled au type NMTOKENS ; augmenté l'attribut namelist des éléments exit, submit, clear et return comme de type NMTOKENS mais autorisé le caractère $, pour les soumissions des variables fictives (annexe B, annexe O)
• Restreint le modèle de contenu de l'élément choice au type PCDATA, et celui des éléments grammar ; précisé que l'élément enumerate ne peut pas apparaître dans un autre élément enumerate (annexe B, annexe O, 2.2.4)
• Précisé que le DTD (conrairement au schéma) ne peut pas exprimer correctement le fait que l'élément metadata ne puisse pas contenir d'éléments provenant d'autres espaces de nommage XML (annexe B)
• Le DTD définit l'attribut xmlns de l'élément vxml comme de type FIXED, avec la valeur par défaut "http://www.w3.org/2001/vxml" (annexe B)
• Aligné le DTD et le schéma sur le texte, de sorte que l'attribut accept de l'élément choice n'ait pas la valeur implicite "exact", s'il n'est pas défini (annexe B, annexe O)
• Précisé, dans l'algorithme FIA, qu'une assignation de application.lastresult$ a lieu après chaque reconnaissance réussie (annexe C)
• Précisé, dans l'algorithme FIA, les correspondances aux grammaires des éléments link à l'intérieur du formulaire, ou du menu, courant, et les correspondances aux grammaires des éléments choice des menus hors du formulaire, ou du menu, courant (annexe C)
• Corrigé l'algorithme FIA tel que la collecte des grammaires actives n'inclut pas les grammaires des éléments dans la chaîne d'appels de l'élément subdialog (annexe C)
• Précisé la phase d'initialisation de l'algorithme FIA en ce qui concerne l'initialisation des éléments script et des éléments de formulaire (annexe C)
• Précisé que des événements peuvent être générés en plusieurs points au cours de l'exécution de l'algorithme FIA, et que la manière dont ils sont gérés dépend de la phase active de l'algorithme FIA (annexe C)
• Précisé que, dans la phase de collecte de l'algorithme FIA, seules les invites issues des éléments d'entrée et de l'élément initial sont sélectionnées, et leur compteur d'invites incrémentés. La mise en file d'attente des invites dans un élément block a lieu lors de l'exécution de l'élément de formulaire (annexe C)
• Dans la phase de traitement de l'algorithme FIA, les actions filled ne sont pas seulement déclenchées par l'entrée d'un énoncé, par exemple, elles peuvent aussi être déclenchées quand la valeur de l'attribut maxtime est atteinte au cours de l'exécution d'un élément record (annexe C)
• Précisé l'emploi des divers délais pour une entrée DTMF (annexe D)
• Si un processeur conforme ne peut pas traiter un élément, ou un attribut, VoiceXML non standard, alors il doit générer un événement error.badfetch (annexe F)
• Des notes explicatives sur la portabilité de l'utilisation des intégrés et de la prise en charge attendue par les plateformes (annexe P)
• Le paramétrage des grammaires vocales et DTMF intégrées (annexe P).
• Le passage des paramètres contradictoires au chiffres intégrés (annexe P).
• La valeur de résultat renvoyée par le type intégré number (annexe P).
• Le code monétaire non défini si non prononcé (annexe P).
• Seules les grammaires de type "digit" et boolean peuvent être paramétrées (annexe P)
• La description de la restitution des valeurs intégrées au moyen de l'élément say-as (annexe P)
• Les grammaires vocales et DTMF des éléments grammar, dans un élément field avec un type intégré défini, s'ajoutent aux grammaires intégrées : elles ne les surclassent pas (annexe P)