‘Voice Extensible Markup Language (VoiceXML) Version 2.0’, 16 mars 2004, en version française

Statut du document traduit

Ceci est une traduction de la recommandation du W3C traitant de la deuxième version du langage de balisage extensible vocal VoiceXML.

Cependant, il ne s'agit pas de la version officielle en français. Seul le document original en anglais a valeur de référence. On peut l'obtenir à : http://www.w3.org/TR/2004/REC-voicexml20-20040316/.

Avertissement

Des erreurs ont pu survenir malgré le soin apporté à ce travail.

Notes sur la traduction

Certains concepts sont difficiles à rendre en français, ou peuvent bénéficier d'une explication. Par moment, les expressions originales en anglais viennent en renfort dans le texte sous cette forme :
ex. traduction [ndt. translation]

D'autres expressions intègrent également les versions originales en anglais, qui apparaissent d'une manière ou d'une autre (selon le navigateur), lorsque l'on laisse le pointeur de la souris au-dessus d'elles. Elles se présentent sous cette forme :
ex. Agent utilisateur

Finalement, les liens menant à d'autres documents du W3C déjà traduits sont discrètement doublés vers leur traduction, comme ceci :
ex. un lien→vf  vers un document du W3C.

Archives compressées et autres formats

Cette traduction est disponible au format HTML sous forme d'archive compressée et, le cas échéant, dans d'autres formats à l'adresse http://www.yoyodesign.org/doc/w3c/w3c.html.

Autres documents traduits

On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/2003/03/Translations/byLanguage?language=fr

Avis légal

Copyright © 1994-2004 World Wide Web Consortium,
(Massachusetts Institute of Technology,
European Research Consortium for Informatics and Mathematics,
Keio University).
Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.


W3C

Le langage de balisage extensible vocal (VoiceXML) version 2.0

Recommandation du W3C du 16 mars 2004

Cette version :
http://www.w3.org/TR/2004/REC-voicexml20-20040316/
Dernière version :
http://www.w3.org/TR/voicexml20/
Version précédente :
http://www.w3.org/TR/2004/PR-voicexml20-20040203/
Rédacteurs :
Scott McGlashan, Hewlett-Packard (rédacteur en chef)
Daniel C. Burnett, Nuance Communications
Jerry Carter, expert invité
Peter Danielsen, Lucent (jusqu'en octobre 2002)
Jim Ferrans, Motorola
Andrew Hunt, ScanSoft
Bruce Lucas, IBM
Brad Porter, Tellme Networks
Ken Rehor, Vocalocity
Steph Tryphonas, Tellme Networks

Veuillez consulter l'errata de ce document, lequel peut contenir des corrections normatives.

Voir également d'éventuelles traductions.


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

Table des matières détaillée


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 :

L'interpréteur VoiceXML se place entre le serveur de documents et la plateforme d'implémentation
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 :

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 :

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é.

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).

Un document racine sur une séquence de 3 documents
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

Tableau 1 : Les éléments du langage VoiceXML
Élément Objectif Chapitre
assign Assigne une valeur à une variable 5.3.2
audio Lit un fichier son au sein d'un élément prompt 4.1.3
block Un conteneur pour un code exécutable (non interactif) 2.3.2
catch Capture un événement 5.2.2
choice Définit un élément de menu 2.2.2
clear Efface une ou plusieurs variables d'élément de formulaire 5.3.3
disconnect Déconnecte une session 5.3.11
else Employé dans les éléments if 5.3.4
elseif Employé dans les éléments if 5.3.4
enumerate Raccourci pour l'énumération des choix dans un menu 2.2.4
error Capture un événement erreur 5.2.3
exit Sort d'une session 5.3.9
field Déclare un champ de saisie dans un formulaire 2.3.1
filled Une action exécutée quand les champs sont remplis 2.4
form Un dialogue pour la présentation d'informations et la collecte de données 2.1
goto Aller à un autre dialogue dans le même document ou un document différent 5.3.7
grammar Indique une grammaire de reconnaissance vocale ou une grammaire DTMF 3.1
help Capture un événement aide 5.2.3
if Logique conditionnelle simple 5.3.4
initial Déclare une logique initiale sur une entrée dans un formulaire (à initiative mixte) 2.3.3
link Définit une transition commune à tous les dialogues dans la portée du lien 2.5
log Génère un message de débogage 5.3.13
menu Un dialogue pour choisir entre plusieurs destinations 2.2.1
meta Définit un élément de métadonnée en tant que couple nom/valeur 6.2.1
metadata Définit une métainformation en utilisant un schéma de métadonnée 6.2.2
noinput Capture un événement non-entrée 5.2.3
nomatch Capture un événement non-correspondance 5.2.3
object Interagit avec une extension personnalisée 2.3.5
option Indique une option dans un élément field 2.3.1.3
param Paramètre dans un élément object ou subdialog 6.4
prompt Place en file d'attente la synthèse vocale et la sortie audio vers l'utilisateur 4.1
property Contrôle les paramètres de la plateforme d'implémentation. 6.3
record Enregistre un échantillon audio 2.3.6
reprompt Joue la file d'attente sur un champ lorsque celui-ci est revisité après un événement 5.3.6
return Retour d'un sous-dialogue. 5.3.10
script Définit un bloc de logique de script ECMAScript côté client 5.3.12
subdialog Invoque un dialogue en tant que sous-dialogue du dialogue courant 2.3.4
submit Soumet des valeurs à un serveur de documents 5.3.8
throw Suscite un événement. 5.2.1
transfer Transfère l'appelant vers une autre destination 2.3.7
value Insère la valeur d'une expression dans une invite 4.1.4
var Déclare une variable 5.3.1
record L'élément de niveau supérieur dans chaque document VoiceXML 1.5.1

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 :

Tableau 2 : Les attributs de l'éléments vxml
version La version du langage VoiceXML du document (obligatoire). Le numéro de version courant est "2.0".
xmlns L'espace de nommage désigné pour le langage VoiceXML (obligatoire). L'espace de nommage du langage VoiceXML est défini comme étant http://www.w3.org/2001/vxml.
xml:base L'adresse URI de base du document, défini dans le document [XML-BASE]. Comme dans le langage [HTML], c'est l'adresse URI que toutes les appels relatifs dans le document prennent comme adresse de base.
xml:lang L'identificateur de langue du document. Si absent, la valeur implicite est propre à la plateforme.
application L'adresse URI du document racine d'application du document, le cas échéant.

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 :

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 :

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.

Les transitions qui préservent le contexte racine
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.

Les transitions qui initialisent le contexte racine
Figure 4 : Les transitions qui initialisent le contexte racine

  1. 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.
  2. 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.
  3. 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.

Un sous-dialogue composé de plusieurs documents revenant du dernier document de sous-dialogue.
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.

Un sous-dialogue composé de plusieurs documents revenant du premier document sous-dialogue
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 :

Les attributs de formulaire sont :

Tableau 3 : Les attributs de l'élément form
id Le nom du formulaire. S'il est fourni, on peut appeler le formulaire dans le document ou depuis un autre document. Par exemple : <form id="meteo">, <goto next="#meteo">.
scope La portée implicite des grammaires de formulaire. Pour la valeur "dialog", les grammaires de formulaire ne sont actives que dans le formulaire. Pour la valeur "document", elles sont actives pour la durée de n'importe quel dialogue dans le même document. Si la valeur est "document" et que le document est un document racine d'application, alors les grammaires de formulaire sont actives pour la durée de n'importe quel dialogue dans n'importe quel document de cette application. Remarquez que la portée des grammaires de formulaire individuel est prioritaire sur la portée implicite. Par exemple, dans les documents non-racines, si on a un formulaire avec une portée valant implicitement "dialog" et une grammaire de formulaire dont la portée vaut "document", alors cette grammaire est active dans n'importe quel dialogue du document.

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 :

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 :

Tableau 4 : Les éléments d'entrée
field Un élément d'entrée dont la valeur s'obtient via des grammaires ASR ou DTMF.
record Un élément d'entrée dont la valeur est un message sonore enregistré par l'utilisateur. Un élément record pourrait, par exemple, recueillir un message électronique vocal.
transfer Un élément d'entrée qui transfère l'utilisateur vers un autre numéro de téléphone. Si le transfert renvoie une commande, la variable du champ recevra le statut résultant.
object Cet élément d'entrée invoque un objet propre à une plateforme avec divers paramètres. Le résultat de l'objet de plateforme est un objet ECMAScript de type Object. Un objet de plateforme pourrait revêtir la forme d'un dialogue intégré qui recueillerait les renseignements d'une carte de crédit. Un autre pourrait recueillir un message textuel au moyen d'une certaine méthode propriétaire de saisie de texte DTMF. Les implémentations n'ont pas obligation de produire des objets propres à une plateforme, bien qu'elles doivent gérer l'élément object en suscitant un événement error.unsupported.objectname si l'objet propre à une plateforme particulière n'était pas reconnu (remarquez que la chaîne objectname dans error.unsupported.objectname est fixe et ne se remplace donc pas par le nom de l'objet non reconnu ; la variable d'événement spéciale "_message" peut fournir d'autres informations d'erreur plus spécifiques, comme décrit dans le chapitre 5.2.2).
subdialog Cet élément d'entrée se comporte grossièrement comme un appel de fonction. Il invoque un autre dialogue dans le document courant ou bien un autre document VoiceXML. Il renvoie un objet ECMAScript de type Object comme résultat.

2.1.2.2 Les éléments de commande

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

Tableau 5 : Les éléments de commande
block Une séquence de déclarations procédurales servant pour les invites et les calculs, mais pas pour le recueil d'une entrée. Un bloc contient une variable d'élément de formulaire (normalement implicite) dont la valeur doit être vérifiée avant qu'il ne puisse être interprété.
initial Cet élément détermine l'interaction initiale dans un formulaire à initiative mixte. Son invite devrait être écrite de manière à encourager l'utilisateur à dire quelque chose qui corresponde avec une grammaire de niveau formulaire. Lorsqu'au moins une variable d'élément de formulaire est remplie comme résultat d'une reconnaissance pendant un élément initial, alors la variable d'élément de formulaire de l'élément initial se vérifie, ce qui l'exclut comme alternative pour l'algorithme FIA.

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 :

Tableau 6 : Les attributs communs des éléments de formulaire
name Le nom d'une variable d'élément de formulaire, dans la portée d'un dialogue, qui contiendra la valeur de l'élément de formulaire.
expr La valeur initiale de la variable d'élément de formulaire ; par défaut, c'est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne s'exécutera pas, à moins d'effacer la variable d'élément de formulaire.
cond Une expression à évaluer conjointement au test de la variable d'élément de formulaire. Si l'attribut est absent, sa valeur implicite vaut "true" ou alors, dans le cas de l'élément initial, c'est un test pour déterminer si une quelconque variable d'élément de formulaire a été remplie.

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 :

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 une entrée est filtrée par une grammaire dans ce formulaire, alors :

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 :

Tableau 7 : Les attributs de l'élément menu
id L'identificateur du menu. Il permet aux éléments goto et submit de cibler le menu.
scope La portée des grammaires du menu. Si sa valeur est "dialog" (la valeur implicite), alors les grammaires du menu ne sont actives que lorsque l'utilisateur entre dans le menu. Si sa valeur est "document", alors les grammaires sont actives pour la totalité du document (ou si le menu se trouve dans le document racine d'application, pour n'importe quel document chargé faisant partie de l'application).
dtmf Lorsque sa valeur est fixée à "true", les neuf premiers choix, qui n'auraient pas défini explicitement une valeur pour l'attribut dtmf, recevront les valeurs implicites "1", "2", etc. Les choix restants, qui n'auraient pas défini explicitement une valeur pour l'attribut dtmf, ne recevront pas de valeurs DTMF (et, par conséquent, ne pourront pas faire l'objet d'une correspondance via une saisie DTMF). Si des choix définissent des séquences DTMF propres qui sont autre chose que des tonalités "*", "#" ou "0", alors une erreur error.badfetch sera suscitée. La valeur implicite de l'attribut est "false".
accept Lorsque sa valeur est fixée à "exact" (la valeur implicite), alors le texte des éléments choice composant le menu définit la phrase exacte à reconnaître. Pour une valeur de "approximate", le texte des éléments choice définit une phrase de reconnaissance approximative (comme décrit dans le chapitre 2.2.5). Chaque élément choice peut surcharger ce réglage.

2.2.2 L'élément choice

L'élément choice a plusieurs usages  :

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

Tableau 8 : Les attributs de l'élément choice
dtmf La séquence DTMF pour ce choix. Elle équivaut à une grammaire DTMF simple et les propriétés DTMF (voir le chapitre 6.3.3) s'appliquent à la reconnaissance de la séquence. Contrairement aux grammaires DTMF, les blancs sont optionnels : dtmf="123#" équivaut à dtmf="1 2 3 #".
accept Surcharge le réglage de l'attribut accept de l'élément menu pour ce choix particulier. Lorsque sa valeur est "accept" (la valeur implicite), le texte de l'élément choice définit la phrase exacte à reconnaître. Pour la valeur "approximate", le texte de l'élément choice définit une phrase de reconnaissance approximative (comme décrit dans le chapitre 2.2.5).
next L'adress URI du dialogue ou du document à suivre.
expr Définit une expression à évaluer comme une adresse URI vers laquelle effectuer une transition au lieu de définir un attribut next.
event Définit un événement à susciter au lieu de définir un attribut next.
eventexpr Une expression ECMAScript correspondant au nom de l'événement à susciter.
message La chaîne du message fournissant une explication supplémentaire concernant l'événement qui est suscité. Le message est disponible comme valeur d'une variable dans la portée de l'élément catch concerné, voir le chapitre 5.2.2.
messageexpr Une expression ECMAScript correspondant à la chaîne du message.
fetchaudio Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchaudio.
fetchhint Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentfetchhint.
fetchtimeout Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentmaxage.
maxstale Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentmaxstale.

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 :

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 :

À 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 :

Tableau 9 : Les attributs de l'élément field
name La variable d'élément de formulaire dans la portée du dialogue qui contiendra le résultat. Le nom doit être unique parmi les éléments de formulaire dans le formulaire. S'il n'est pas unique, alors un événement error.badfetch est suscité quand le document est appelé. Le nom doit respecter les conventions de nommage des variables décrites dans le chapitre 5.1.
expr La valeur initiale de la variable d'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si on initialise la variable, alors l'élément de formulaire ne sera pas visitée, à moins de l'effacer.
cond Une expression dont l'évaluation de sa valeur, après conversion en un booléen, doit donner "true" pour que l'élément de formulaire soit visité. L'élément de formulaire pourra également être visité si l'attribut n'est pas défini.
type Le type du champ, à savoir le nom d'un type de grammaire intégré (voir l'annexe P). La prise en charge des types de grammaire intégrés par la plateforme est optionnelle. Si la plateforme ne prend pas en charge le type intégré indiqué, alors un événement error.unsupported.builtin est suscité.
slot Le nom de la facette de grammaire utilisée pour peupler la variable (si elle est absente, alors sa valeur implicite est le nom de la variable). Cet attribut trouve une utilité dans le cas où le format de grammaire employé possède un mécanisme permettant de renvoyer des ensembles de couples facette/valeur et que les noms des facettes diffèrent de ceux des variables des éléments de formulaire.
modal Si sa valeur est "false" (la valeur implicite), alors toutes les grammaires sont actives pendant la collecte des données de ce champ. Pour la valeur "true", alors seules les grammaires du champ sont actives : toutes les autres sont temporairement désactivées.

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).

Tableau 10 : Les variables fictives de l'élément field
nom$.utterance La chaîne brute des mots reconnus. 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 de chiffres filtrée.
nom$.inputmode Le mode dans lequel l'entrée d'utilisateur a été fournie : "dtmf" ou "voice".
nom$.interpretation Une variable ECMAScript contenant l'interprétation, comme décrit dans le chapitre 3.1.5.
nom$.confidence

Le niveau de fiabilité du champ nom, défini dans l'intervalle 0.0-1.0. Une valeur de "0.0" indique une fiabilité minimale ; inversement, une valeur de "1.1" indique une fiabilité maximale.

Une plateforme peut se servir de la fiabilité de l'énoncé (la valeur de la variable application.lastresult$.confidence) comme valeur pour nom$.confidence. Cette distinction entre niveau de fiabilité du champ et niveau de fiabilité de l'énoncé est propre à la plateforme.

L'interprétation plus spécifique d'une valeur de fiabilité dépend de la plateforme puisque le calcul de celle-ci différera probablement d'une plateforme à l'autre.

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 :

Tableau 11 : Les attributs de l'élément option
dtmf Une séquence DTMF optionnelle pour cette option. Elle équivaut à une grammaire DTMF simple et les propriétés DTMF (voir le chapitre 6.3.3) s'appliquent lors de la reconnaissance de la séquence. À la différence des grammaires DTMF, les blancs sont optionnels : dtmf="123#" est équivalent à dtmf="1 2 3 #". Si l'attribut n'est pas défini, aucune séquence DTMF ne sera associée à cette option et elle ne peut donc pas être filtrée au moyen d'une grammaire DTMF.
accept Lorsque sa valeur est fixée à "exact" (la valeur implicite), alors le texte de l'élément option définit la phrase exacte à reconnaître. Pour la valeur "approximate", le texte de l'option définit une phrase de reconnaissance approximative (comme décrit dans le chapitre 2.2.5).
value La chaîne à assigner à la variable d'élément de formulaire du champ lorsque l'utilisateur sélectionne cette option, que cette sélection se fasse par la voix ou bien par le biais de tonalités DTMF. L'assignation implicite est le contenu de type CDATA de l'élément option, les blancs de tête et de queue étant supprimés. En l'absence d'un contenu, alors c'est la séquence DTMF qui sera utilisée à la place. Si on ne définit ni contenu de type CDATA ni séquence DTMF, alors la valeur implicite de l'assignation est "undefined" et la variable d'élément de formulaire du champ n'est pas remplie.

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 :

Tableau 12 : Les attributs de l'élément block
name Le nom de la variable d'élément de formulaire servant au suivi de l'éligibilité pour exécution du bloc ; la valeur implicite est une variable interne inaccessible.
expr La valeur initiale de la variable de l'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne sera pas visité, à moins d'effacer la variable d'élément de formulaire.
cond Une expression dont l'évaluation, après conversion en une valeur booléenne, doit valoir "true" pour que l'élément de formulaire soit visité.

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 :

Tableau 13 : Les attributs de l'élément initial
name Le nom de la variable d'élément de formulaire servant au suivi de l'éligibilité pour exécution de l'élément initial ; la valeur implicite est une variable interne inaccessible.
expr La valeur initiale de la variable de l'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne sera pas visité, à moins d'effacer la variable d'élément de formulaire.
cond Une expression dont l'évaluation, après conversion en une valeur booléenne, doit valoir "true" pour que l'élément de formulaire soit visité.

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 :

Tableau 14 : Les attributs de l'élément subdialog
name Le résultat renvoyé depuis le sous-dialogue, à savoir un objet ECMAScript dont les propriétés sont celles définies dans l'attribut namemlist de l'élément return.
expr La valeur initiale de la variable de l'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne sera pas visité, à moins d'effacer la variable d'élément de formulaire.
cond Une expression dont l'évaluation, après conversion en une valeur booléenne, doit valoir "true" pour que l'élément de formulaire soit visité.
namelist La liste des variables à soumettre. Par défaut, aucune variable n'est soumise. Si un attribut namelist est défini, alors il peut contenir des références de variables individuelles lesquelles sont soumises avec la même orthographe que celle employée dans la valeur de l'attribut. On peut appeler les variables VoiceXML et ECMAScript déclarées. Si on appelle une variable non déclarée dans la liste de noms, alors un événement error.semantic est suscité (voir le chapitre 5.1.1).
src L'adresse URI du sous-dialogue.
srcexpr Une expression ECMAScript produisant l'adresse URI du sous-dialogue
method Voir le chapitre 5.3.8.
enctype Voir le chapitre 5.3.8.
fetchaudio Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchaudio.
fetchtimeout Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchtimeout.
fetchhint Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentfetchhint
maxage Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentmaxage.
maxstale Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentmaxstale.

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 :

Tableau 15 : Les attributs de l'élément object
name Lorsque l'objet est évalué, il assigne à cette variable une valeur ECMAScript dont il définit le type.
expr La valeur initiale de la variable de l'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne sera pas visité, à moins d'effacer la variable d'élément de formulaire.
cond Une expression dont l'évaluation, après conversion en une valeur booléenne, doit valoir "true" pour que l'élément de formulaire soit visité.
classid L'adresse URI définissant l'emplacement de l'implémentation de l'objet. Les conventions d'adresse URI dépendent des plateformes.
codebase Le chemin de base utilisé pour résoudre les adresse URI relatives définies par les attributs classid, data et archive. Par défaut, c'est l'adresse URI de base du document courant.
codetype Le type de contenu des données attendues dans le téléchargement de l'objet indiqué par l'attribut classid. Par défaut, sa valeur est celle de l'attribut type.
data L'adresse URI définissant l'emplacement des données de l'objet. Si c'est une adresse URI relative, elle se résoud relativement à l'attribut codebase.
type Le type de contenu des données définies par l'attribut data.
archive Une liste d'adresse URI, séparées par des espaces, des archives contenant des ressources concernant l'objet, ce qui peut comprendre les ressources indiquées par les attributs classid et data. Les adresses URI relatives se résolvent relativement à l'attribut codebase.
fetchhint Voir le chapitre 6.1. La valeur implicite est celle de la propriété objectfetchhint.
fetchtimeout Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. La valeur implicite est celle de la propriété objectmaxage.
maxstale Voir le chapitre 6.1. La valeur implicite est celle de la propriété objectmaxstale.

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.

Diagramme de temporisation montrant un exemple invitant un utilisateur à une entrée puis enregistrant la voix de celui-ci.
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 :

Tableau 16 : Les attributs de l'élément record
name

La variable d'élément d'entrée qui va contenir l'enregistrement.

Remarquez que l'implémentation de cette variable peut varier d'une plateforme à l'autre (bien que toutes les plateformes doivent gérer son comportement dans les éléments audio et submit, comme décrit dans cette spécification).

expr La valeur initiale de la variable de l'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne sera pas visité, à moins d'effacer la variable d'élément de formulaire.
cond Une expression dont l'évaluation, après conversion en une valeur booléenne, doit valoir "true" pour que l'élément de formulaire soit visité.
modal Lorsque sa valeur est "true" (la valeur implicite), alors aucune des grammaires vocales et DTMF non locales n'est active pendant l'enregistrement. Pour une valeur "false", les grammaires vocales et DTMF non locales sont actives.
beep Lorsque sa valeur est "true", une tonalité est produite juste avant l'enregistrement. La valeur implicite est "false"
maxtime La durée maximale d'enregistrement. Sa valeur est une indication de temps (voir le chapitre 6.5). La valeur implicite est propre à la plateforme.
finalsilence Le délai de silence qui indique la fin du discours. Sa valeur est une indication de temps (voir le chapitre 6.5). La valeur implicite est propre à la plateforme.
dtmfterm Lorsque sa valeur est "true", n'importe quelle touche DTMF non filtrée par une grammaire active sera traitée comme la correspondance d'une grammaire DTMF locale (anonyme) active. La valeur implicite est "true".
type Le format de média de l'enregistrement résultant. Les plateformes doivent reconnaître les formats de fichier son indiqués dans l'annexe E (d'autres formats peuvent aussi être gérés). La valeur implicite, propre à la plateforme, devrait correspondre à l'un des formats obligatoires.

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

Tableau 17 : Les variables fictives de l'élément record
nom$.duration La durée de l'enregistrement en millisecondes.
nom$.size La taille de l'enregistrement en octets.
nom$.termchar Si la valeur de l'attribut dtmfterm est "true" et que l'utilisateur a terminé l'enregistrement en appuyant une touche DTMF, alors la valeur de cette variable fictive est celle de la touche appuyée (par exemple, #). Sinon, la valeur est "undefined".
nom$.maxtime C'est un booléen évalué à "true" si l'enregistrement s'est terminé parce que la durée maximale a été atteinte.

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 :

Tableau 18 : Les attributs de l'élément transfer
name Stocke le résultat d'une tentative de transfert de type pont. Dans le cas d'un transfert de type aveugle, cette variable n'est pas définie.
expr La valeur initiale de la variable de l'élément de formulaire ; la valeur implicite est la valeur ECMAScript "undefined". Si elle est initialisée, alors l'élément de formulaire ne sera pas visité, à moins d'effacer la variable d'élément de formulaire.
cond Une expression dont l'évaluation, après conversion en une valeur booléenne, doit valoir "true" pour que l'élément de formulaire soit visité.
dest L'adresse URI de destination (téléphone, adresse de téléphonie IP). Les plateformes doivent gérer la syntaxe URL tel: décrite dans le document [RFC2806] et peuvent gérer d'autres systèmes d'adressage fondés sur des adresses URI.
destexpr Une expression ECMAScript produisant l'adresse URI de destination.
bridge

Détermine si la plateforme participe à la connexion entre l'appelant et l'appelé.

bridge="true"

Transfert de type pont. La plateforme ajoute l'appelé dans la connexion. L'interprétation du document est suspendue jusqu'à ce que le transfert de l'appel soit terminé. La plateforme demeure dans la connexion pour la durée de l'appel transféré ; pendant le transfert, l'écoute est contrôlée par un éventuel élément grammar inclus.

Si l'appelant se déconnecte en raccrochant ou si le réseau déconnecte l'appelant, alors la plateforme suscite un événement connection.disconnect.hangup.

Si la connexion est interrompue pour une quelconque autre raison, ce résultat est signalé dans l'attribut name (voir le tableau suivant).

bridge="false"

Transfert de type aveugle (par défaut). La plateforme redirige l'appelant vers l'appelé sans demeurer dans la connexion et elle ne surveille pas le résultat.

La plateforme suscite immédiatement un événement connection.disconnect.transfer, que le transfert ait réussi ou non.

connecttimeout Le temps d'attente en essayant de connecter l'appel avant de renvoyer la réponse "noanswer". La valeur est une indication de temps (voir le chapitre 6.5). Ne s'applique que si l'attribut bridge a la valeur "true". La valeur implicite est propre à la plateforme.
maxtime La durée permise pour l'appel ou la valeur "0s" si aucune limite n'est imposée. La valeur est une indication de temps (voir le chapitre 6.5). Ne s'applique que si l'attribut bridge a la valeur "true". La valeur implicite est "0s".
transferaudio

L'adresse URI de la source sonore à jouer pendant la tentative de transfert (avant la réponse distante).

Si la ressource ne peut pas être ramenée, alors l'erreur est ignorée et le transfert continue ; ce que l'appelant entend est propre à la plateforme.

aai

Des informations interapplications (AAI). Une chaîne contenant les données envoyées à une application distante, et disponibles dans la variable de session session.connection.aai.

La transmission de données AAI peut dépendre des passerelles de réseau et des traductions de données de la signalisation (par exemple, ISDN vers SIP) ; l'état des données envoyées à un site distant n'est pas connu ni signalé.

Bien que toutes les plateformes doivent gérer l'attribut aai, elles ne sont pas obligées d'envoyer des données AAI et n'ont pas besoin de prendre en charge la réception de données AAI. Les plateformes qui ne peuvent recevoir de données AAI doivent fixer la valeur de la variable session.connection.aai à la valeur ECMAScript "undefined". Le mécanisme de transmission sous-jacent peut imposer des limites à la longueur des données.

aaiexpr

Une expression ECMAScript produisant les données AAI.

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.

La plateforme d'implémentation VoiceXML n'intervient pas dans la connexion sonore entre l'appelant et l'appelé après un transfert de type aveugle.
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 :

Tableau 19 : Les variables fictives de l'élément transfer
nom$.duration

La durée d'un transfert d'appel en secondes.

La durée vaut "0" si la tentative d'appel a été terminée par l'appelant (au moyen d'une commande DTMF) avant que l'appel sortant ne commence.

nom$.inputmode

Le mode d'entrée de la commande de terminaison ("dtmf" ou "voice"), ou la valeur "undefined" si le transfert n'a pas été terminé par une correspondance de grammaire.

nom$.utterance Le texte de l'énoncé, si le transfert a été terminé par une entrée de reconnaissance vocale, ou le résultat DTMF, si le transfert a été terminé par une entrée DTMF ; sinon, la valeur "undefined".

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.

Tableau 20 : Les résultats d'un transfert de type aveugle
Action Valeur de la variable d'élément de formulaire Événement ou erreur Cause
le transfert commence "undefined" connection.disconnect.transfer Il y a eu une tentative de transfert de l'appelant sur une autre ligne et elle ne reviendra pas.
l'appelant annule le transfert avant que l'appel sortant ne commence "near_end_disconnect" L'appelant a annulé la tentative de transfert via une commande vocale ou DTMF avant que l'appel sortant ne commence (au cours de la lecture des sons en file d'attente).
le transfert se termine "unknown" Le transfert est terminé mais la cause en est inconnue.

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.

Une plateforme d'implémentation VoiceXML (le tiers B) intervenant dans un transfert de type pont entre un appelant et un appelé.
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 :

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 :

Tableau 21 : Les résultats d'un transfert de type pont avant l'établissement de la connexion
Action Valeur de la variable de l'élément de formulaire Événement Cause
l'appelant se déconnecte connection.disconnect.hangup L'appelant raccroche.
l'appelant déconnecte l'appelé "near_end_disconnect" L'appelant a forcé la déconnexion de l'appelé via une commande vocale ou DTMF.
l'appelé est occupé "busy" L'appelé était occupé.
le réseau est encombré "network_busy" Un réseau intermédiaire a refusé l'appel.
l'appelé ne répond pas "noanswer" Il n'y a pas eu de réponse dans le temps imparti par l'attribut connecttimeout.
--- "unknown" Le transfert est interrompu mais la cause en est inconnue.

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

Tableau 22 : Les résultats d'un transfert de type pont après établissement de la connexion
Action Valeur de la variable de l'élément de formulaire Événement Cause
l'appelant se déconnecte connection.disconnect.hangup L'appelant raccroche.
l'appelant se déconnecte "near_end_disconnect" L'appelant a forcé la déconnexion de l'appelé via une commande vocale ou DTMF.
la plateforme déconnecte l'appelé "maxtime_disconnect" L'appelé a été déconnecté par la plateforme parce que la durée de l'appel a atteitn la valeur de l'attribut maxtime.
le réseau déconnecte l'appelé "network_disconnect" Le réseau a déconnecté l'appelé de la plateforme.
l'appelé se déconnecte "far_end_disconnect" L'appelé a raccroché.
--- "unknown" Le transfert s'est interrompu mais la cause en est inconnue.

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 :

Tableau 23 : Les variables fictives de l'élément transfer
nom$.duration

La durée d'un transfert d'appel en secondes.

La durée vaut "0" si le transfert d'appel a été terminé par l'appelant (au moyen d'une commande vocale ou DTMF) avant qu'on y réponde.

nom$.inputmode Le mode d'entrée de la commande de terminaison ("dtmf" ou "voice"), ou la valeur "undefined" si le transfert n'a pas été terminé par une correspondance de grammaire.
nom$.utterance Le texte énoncé, si le transfert a été terminé par une commande vocale, ou le résultat DTMF, si celui-ci a été terminé par une commande DTMF ; sinon sa valeur est "undefined".

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é :

Tableau 24 : Les événements suscités au cours du transfert
Événement Cause Type de transfert
connection.disconnect.hangup L'appelant raccroche. pont
connection.disconnect.transfer Une tentative pour transférer l'appelant sur une autre ligne a eu lieu et elle ne reviendra pas. aveugle

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

Tableau 25 : Les erreurs de l'échec d'un transfert
Erreur Cause Type de transfert
error.connection.noauthorization L'appelant n'est pas autorisé à appeler la destination. aveugle et pont
error.connection.baddestination L'adresse URI de la destination est malformée. aveugle et pont
error.connection.noroute La plateforme est dans l'impossibilité de placer un appel vers la destination. pont
error.connection.noresource La plateforme est dans l'impossibilité d'allouer les ressources pour placer l'appel. pont
error.connection.protocole.nnn La pile de protocoles pour cette connexion a levé une exception qui ne correspond à aucun des autres événements error.connection. pont
error.unsupported.transfer.blind La plateforme ne gère pas le transfert de type aveugle. aveugle
error.unsupported.transfer.bridge La plateforme ne gère pas le transfert de type pont. pont
error.unsupported.uri La platforme ne gère pas le format d'adresse URI employé. La variable spéciale _message (voir le chapitre 5.2.2) contiendra la chaîne "The URI x is not a supported URI format", où la variable x représente l'adresse URI indiquée par l'attribut dest, ou bien destexpr, de l'élément transfer. aveugle et pont

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.

Le diagramme des séquences et des temporisations au cours d'un transfert de type pont.
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 :

Tableau 26 : Les attributs de l'élément filled
mode L'attribut admet comme valeur soit "all" (la valeur implicite), soit "any". Pour la valeur "any", l'action est exécutée lorsque n'importe quel des éléments d'entrée définis est rempli par la dernière entrée d'utilisateur. Pour la valeur "all", l'action est exécutée lorsque tous les éléments d'entrée mentionnés sont remplis et qu'au moins l'un d'entre eux a été rempli par la dernière entrée d'utilisateur. Un élément filled contenu dans un élément d'entrée ne peut pas définir d'attribut mode ; auquel cas, la plate forme suscitera un événement error.badfetch à la lecture du document.
namelist Les éléments d'entrée à partir desquels déclencher l'exécution. Pour un élément filled dans un formulaire, la valeur implicite de l'attribut namelist se compose des noms (explicites et implicites) des éléments d'entrée du formulaire. Un élément filled dans un élément d'entrée ne peut pas définir d'attribut namelist (dans ce cas, la valeur de l'attribut est le nom de l'élément d'entrée) ; si on définit un attribut namelist, alors la plateforme suscite un événement error.badfetch à la lecture du document. Remarquez que les éléments de commande sont interdits dans cette liste ; un événement error.badfetch sera suscité lorsque le document contiendra un élément filled avec un attribut namelist appelant une variable d'élément de commande.

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 :

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.

Conceptuellement, on peut considérer l'élément link comme étant en deux parties : une condition et une action. La condition correspond au contenu de l'élément link, c'est-à-dire, la ou les grammaires qui doivent être sollicitées pour que le lien soit activé. L'action est définie par les attributs de l'élément, c'est-à-dire, vers où effectuer la transition ou quel événement susciter. La condition est résolue/évaluée lexicalement tandis que l'action l'est dynamiquement. En particulier, cela signifie que :

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

Tableau 27 : Les attributs de l'élément link
next L'adresse URI de destination. Elle correspond à un document (éventuellement avec une ancre indiquant le dialogue de départ) ou à un dialogue dans le document courant (juste une ancre).
expr Comme l'attribut next, sauf que l'adresse URI est déterminée dynamiquement en évaluant l'expression ECMAScript donnée.
event L'événement à susciter lorsque l'entrée d'utilisateur correspond à l'une des grammaires du lien.
eventexpr Une expression ECMAScript se réduisant au nom de l'événement à susciter lorsque l'entrée d'utilisateur correspond à l'une des grammaires du lien.
message Une chaîne message apportant des explications supplémentaires concernant l'événement suscité. Le message est disponible en tant que valeur d'une variable dans la portée de l'élément catch, voir le chapitre 5.2.2.
messageexpr Une expression ECMAScript se réduisant à la chaîne message.
dtmf La séquence DTMF du lien. Elle équivaut à une grammaire DTMF simple et les propriétés DTMF (voir le chapitre 6.3.3) s'appliquent à la reconnaissance de la séquence. Contrairement aux grammaires DTMF, les blancs sont optionnels : les déclarations dtmf="123#" et dtmf="1 2 3 #" sont équivalentes. L'attribut peut s'utiliser en même temps que d'autres éléments grammar : le lien est activé lorsque l'entrée d'utilisateur correspond à une grammaire du lien ou à la séquence DTMF.
fetchaudio Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchaudio.
fetchhint Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentfetchhint.
fetchtimeout Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentmaxage.
maxstale Voir le chapitre 6.1. La valeur implicite est celle de la propriété documentmaxstale.

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 :

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.

Tableau 28 : Les éléments SRGS (forme XML)
Élément Usage Chapitre
([SRGS])
grammar L'élément racine d'une grammaire XML 4.→vf
meta Une déclaration en-tête du métacontenu d'un équivalent HTTP 4.11.1→vf
metadata Une déclaration en-tête d'un contenu de métadonnées XML 4.11.2→vf
lexicon Une déclaration en-tête d'un lexique de prononciation 4.10→vf
rule Déclare une extension de règle nommée d'une grammaire 3.→vf
token Définit un mot ou une autre entité qui peut servir d'entrée 2.1→vf
ruleref Désigne une règle définie localement ou extérieurement 2.2→vf
item Définit une extension dont la répétition et la probabilité d'apparition sont optionnels 2.3→vf
<one-of> Définit un ensemble d'extensions de règles alternatives 2.4→vf
example Un élément contenu dans une définition de règle lequel donne un exemple d'entrée correspondant à la règle 3.3→vf
tag Définit une chaîne arbitraire à inclure directement dans une extension et qui peut être utilisée pour une interprétation sémantique 2.6→vf

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 :

Tableau 29 : Les attributs de l'élément grammar hérités de la spécification SRGS
version Définit la version de la grammaire.
xml:lang L'identificateur de langue de la grammaire (par exemple, "fr-CA" pour le français canadien). Si omis, la valeur est héritée en descendant la hiérarchie du document.
mode Définit le mode de la grammaire selon les modes de la spécification [SRGS].
root Définit la règle qui agit comme règle racine de la grammaire.
tag-format Définit le format du contenu de balise de tous les éléments tag dans la grammaire.
xml:base Déclare l'adresse URI de base à partir de laquelle les adresses URI relatives dans la grammaire se résolvent.

Cette déclaration de l'adresse URI de base est prioritaire sur celle de l'élément vxml. Si on omet une déclaration locale, alors la valeur est héritée en descendant la hiérarchie du document.

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 :

Tableau 30 : Les attributs de l'élément grammar rajoutés par VoiceXML
src L'adresse URI indiquant l'emplacement de la grammaire et, en option, un nom de règle dans cette grammaire, si celle-ci est externe. L'adresse URI s'interprète comme l'appel d'une règle, comme défini dans le chapitre 2.2 de la spécification [SRGS], cependant les formes d'appel de règle ne sont pas toutes permises depuis un document VoiceXML. Les possibilités des appels de règles sont décrites en détails après ce tableau.
scope L'attribut admet pour valeur soit "document", ce qui rend la grammaire active dans tous les dialogues du document courant (et les documents terminaux d'une application concernés), soit "dialog", ce qui rend la grammaire active pour le formulaire courant. Si omis, la portée de la grammaire se détermine en examinant l'élément parent. Voir le chapitre 3.1.3 pour des précisions sur les portées incluant des comportements prioritaires.
type

Le type de média préféré de la grammaire. Le type de média de la ressource indiquée par l'appel d'adresse URI dans l'attribut src peut être disponible dans plusieurs versions. L'auteur peut spécifier le type de média préféré via l'attribut type. Lorsque le contenu représenté par une adresse URI est disponible dans plusieurs formats de données, une plateforme VoiceXML peut se servir du type de média préféré pour influencer le choix du format qui sera utilisé. Par exemple, sur un serveur mettant en œuvre une négociation de contenu HTTP, le processeur peut utiliser le type de média préféré pour ordonner les préférences dans la négociation.

La représentation de la ressource issue de la résolution de l'appel d'adresse URI peut se prévaloir de deux types : le type de média déclaré qui est la valeur annoncée de la ressource et le type de média réel qui est le format véritable de son contenu. Le type de média réel devrait être identique au type de média déclaré, mais ce n'est pas toujours le cas (par exemple, en raison d'un serveur HTTP mal configuré qui annonce, pour le type d'un document de grammaire, une valeur "text/plain" au lieu de "application/srgs+xml"). Un système d'adressage URI particulier peut imposer au possesseur de la ressource que celui-ci renvoie toujours, ou parfois, ou jamais le type du média. Le type de média déclaré est la valeur renvoyée par le possesseur de la ressource ou, en l'absence de celle-ci, c'est le type de média préféré donné dans la grammaire. Le type de média déclaré peut être absent si le possesseur de la ressource ne renvoie pas de valeur ou si aucun type de média préféré n'est indiqué. Si le type de média déclaré est présent, alors il fait autorité.

Trois cas particuliers peuvent advenir : le processeur peut ne pas reconnaître le type de média déclaré, auquel cas la plateforme suscite un événement error.unsupported.format ; le type de média déclaré est reconnu mais le type de média réel ne correspond pas, auquel cas la plate forme suscite un événement error.badfetch ; enfin, aucun type de média n'est déclaré et le comportement dépend alors du système d'adressage URI particulier et des capacités du processeur de grammaire. Par exemple, le protocole HTTP 1.1 autorise l'introspection du document (voir le document [RFC2616], chapitre 7.2.1), le schéma de donnée se rabat sur un type de média par défaut, et le mode d'accès au fichier local ne définit aucune solution. Le tableau suivant fournit quelques exemples informatifs :

Requête HTTP 1.1 Accès au fichier local
Type de média renvoyé par le possesseur de la ressource text/plain application/srgs+xml <none> <none>
Type de média préféré apparaissant dans la grammaire Sans objet : le type renvoyé est prioritaire application/srgs+xml <none>
Type de média déclaré text/plain application/srgs+xml application/srgs+xml <none>
Comportement si le type de média réel est "application/srgs+xml" Événement error.badfetch suscité : le type déclaré et le type réel ne correspondent pas Le type déclaré et le type réel correspondent : succès si le processeur reconnaît le type "application/srgs+xml", sinon un événement error.unsupported.format est suscité Particularité du système : le processeur peut examiner le document afin d'en déterminer le type.

Les types de média provisoires du format de grammaire du W3C sont "application/srgs+xml" pour la forme XML et "application/srgs" pour la forme ABNF.

weight Définit le poids de la grammaire. Voir le chapitre 3.1.1.3
fetchhint Voir le chapitre 6.1. La valeur implicite est celle de la propriété grammarfetchhint.
fetchtimeout Voir le chapitre 6.1. La valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. La valeur implicite est celle de la propriété grammarmaxage.
maxstale Voir le chapitre 6.1. La valeur implicite est celle de la propriété grammarmaxstale.

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 :

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

3.1.2 Les grammaires DTMF

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

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.

Tableau 31 : Les affectations des grammaires de niveau formulaire
Champ VoiceXML Valeur ECMAScript affectée Explication
1. <field name="boisson"/> --ou--
<object name="boisson"/> --ou--
<record name="boisson"/>
"eau" Par défaut, un élément d'entrée reçoit la propriété de résultat de niveau supérieur dont le nom correspond à celui de l'élément d'entrée.
2. <field name="..." slot="boisson"/> "eau" Lorsqu'il est défini sur un champ, le nom de facette écrase le nom du champ pour la sélection de la propriété de résultat.
3. <field name="pizza"/> --ou--
<object name="pizza"/> --ou--
<record name="pizza"/> --ou--
<field name="..." slot="pizza"/>
{quantite: "3", taille: "grande", garniture: ["poivron", "champignon"]} Les attributs name ou slot de l'élément d'entrée peuvent sélectionner une propriété qui est une variable ECMAScript non scalaire, de la même façon qu'on sélectionne une valeur scalaire dans l'exemple précédent. Toutefois, l'application doit alors gérer l'inspection des composants de l'objet. Cette méthode ne profite pas de l'algorithme de remplissage de formulaire VoiceXML, dans la mesure où les facettes absentes du résultat ne feraient pas automatiquement l'objet d'une invite. Cela peut suffire pour les situations où le serveur est préparé au traitement d'un objet structuré. Sinon, une application peut préférer la méthode décrite dans l'exemple suivant.
4. <field name="..." slot="pizza.quantite"/>
<field name="..." slot="pizza.taille"/>
"3"
"grande"
L'attribut slot peut servir à sélectionner une sous-propriété du résultat. Cette approche permet de distribuer le résultat sur plusieurs champs.
5. <field name="..." slot="pizza.garniture"/> ["poivron", "champignon"] La propriété sélectionnée peut être un objet composite.

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 :

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 :

Tableau 32 : La correspondance des noms de facette
nom de facette correspondance ou pas ?
undefined ne correspond pas
boisson correspond ; propriété de niveau supérieur
pizza correspond ; propriété de niveau supérieur
accompagnement ne correspond pas ; aucune valeur définie
taille ne correspond pas ; non une propriété de niveau supérieur
pizza.taille correspond ; sous-propriété
pizza.liquide ne correspond pas

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.

Tableau 33 : Les affectations des variables selon la grammaire et le résultat sémantique
application. lastresult$.interpretation résultat de niveau formulaire
(niveauformulaire.grxml)
résultat de niveau champ dans champ x
(fieldx.grxml)
résultat de niveau champ dans champ z
(fieldz.grxml)
= 'bonjour' pas d'affectation ; cycle FIA x = 'bonjour' z = 'bonjour'
= { x: valeurX } x = valeurX x = valeurX z = { x: valeurX }
= { y: valeurY } z = valeurY x = { y: valeurY } z = valeurY
= { z: valeurZ } pas d'affectation ; cycle FIA x = { z: valeurZ } z = { z: valeurZ }
= { x: valeurX,
y: valeurY,
z: valeurZ }
x = valeurX
z = valeurY
x = valeurX z = valeurY
= { a: valeurA
b: valeurB }
pas d'affectation; cycle FIA x = { a: valeurA,
b: valeurB }
z = { a: valeurA,
b: valeurB }

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 :

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 :

Tableau 34 : Les attributs de l'élément prompt
bargein Détermine si l'utilisateur peut interrompre une invite ou non. Sa valeur implicite est celle de la propriété bargein. Voir le chapitre 6.3.4.
bargeintype Fixe le type de l'interruption : vocal pour la valeur "speech" ou par mot magique pour la valeur "hotword". Sa valeur implicite est celle de la propriété bargeintype. Voir le chapitre 6.3.4.
cond Une expression dont l'évaluation de la valeur, après conversion en un booléen, donne "true pour que l'invite soit jouée. La valeur implicite est "true".
count Un nombre permettant d'émettre des invites différentes lorsque l'utilisateur accompli quelque chose répétitivement. Si l'attribut est omis, alors la valeur implicite est "1".
timeout Le délai de temporisation utilisé pour l'entrée d'utilisateur suivante. La valeur est du type désignation de temps (voir le chapitre 6.5). Le délai de temporisation implicite en l'absence d'une entrée est propre à la plateforme.
xml:lang L'identificateur de langue de l'invite. Si l'attribut est omis, la valeur implicite est celle indiquée par l'attribut xml:lang du document.
xml:base Déclare l'adresse URI de base à partir de laquelle les adresses URI relatives dans l'invite seront résolues. Cette déclaration d'adresse URI de base est prioritaire sur celle de l'élément vxml. En l'absence d'une déclaration locale, la valeur est héritée en descendant la hiérarchie du document.

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].

Tableau 35 : Les éléments SSML disponibles dans VoiceXML
Élément Emploi Chapitre
(dans [SSML])
audio Définit les fichiers sons à jouer et le texte à lire. 3.3.1
break Définit une pause dans la sortie vocale. 3.2.3
desc Donne une description d'une source audio non-verbale dans l'élément audio. 3.3.3
emphasis Indique que le texte englobé devrait être prononcé avec emphase. 3.2.2
lexicon Définit un lexique de prononciation pour l'invite. 3.1.4
mark Ignoré par les plateformes VoiceXML. 3.3.2
meta Définit les propriétés meta et http-equiv pour l'invite. 3.1.5
metadata Définit un contenu de métadonnées pour l'invite. 3.1.6
p Identifie le texte englobé comme un paragraphe contenant zéro ou plus phrases. 3.1.7
phoneme Définit une prononciation phonétique pour le texte englobé. 3.1.9
prosody Définit une information prosodique pour le texte englobé. 3.2.4
say-as Définit le type de structure de texte contenu dans l'élément. 3.1.8
s Identifie le texte englobé comme une phrase. 3.1.7
sub Définit un texte sonore de remplacement du texte contenu. 3.1.10
voice Définit les caractéristiques de la voix pour la prononciation du texte. 3.2.1

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 ::

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 :

Tableau 36 : Les attributs de l'élément audio hérités de SSML
src L'adresse URI de l'invite sonore. Voir les formats de fichier son obligatoires dans l'annexe E ; on peut utiliser d'autres formats si la plateforme les gère.

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

Tableau 37 : Les attributs de l'élément audio ajoutés dans VoiceXML
fetchtimeout Voir le chapitre 6.1. Sa valeur par défaut est celle de la propriété fetchtimeout.
fetchhint Voir le chapitre 6.1. Sa valeur par défaut est celle de la propriété audiofetchhint.
maxage Voir le chapitre 6.1. Sa valeur par défaut est celle de la propriété audiomaxage.
maxstale Voir le chapitre 6.1. Sa valeur par défaut est celle de la propriété audiomaxstale.
expr Une expression ECMAScript qui détermine la source du son à jouer. Cette expression est soit une référence à un son enregistré précédemment via l'élément record, soit se résoud en l'adresse URI d'une resource audio à rechercher.

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 :

Tableau 38 : L'attribut de l'élément value
expr L'expression à restituer.

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 :

Tableau 39 : Les valeurs de l'attribut bargeintype
speech L'invite est interrompue dès qu'une commande vocale ou DTMF est détectée. L'invite est arrêtée indépendamment du fait que l'entrée corresponde ou non à une grammaire, quelles que soient les grammaires actives.
hotword L'invite n'est pas arrêtée tant qu'une correspondance complète à une grammaire active ne sera pas détectée. L'entrée qui ne correspond pas à une grammaire est ignorée (remarquez que c'est aussi le cas pendant une période de temporisation) ; par conséquent, il ne sera jamais généré d'événement nomatch quand l'attribut bargein a la valeur "hotword".

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 :

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

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 :

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 :

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 :

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 :

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 :

Tableau 40 : Les portées des variables
session Ce sont des variables, en lecture seule, qui se rapportent à la totalité d'une session d'utilisateur. Elles sont déclarées et fixées par le contexte d'interprétation. Les documents VoiceXML ne peuvent pas déclarer de nouvelles variables de session. Voir le chapitre 5.1.4.
application Ce sont des variables déclarées par des éléments var et script, enfants de l'élément vxml du document racine d'application. Elles sont initialisées au chargement du document racine d'application. Elles existent tant que le document racine d'application est chargé et elles sont visibles par le document racine et tout document terminal d'application chargé. Remarquez que pour une exécution à l'intérieur du document racine d'application, l'expression document.x équivaut à application.x.
document Ce sont des variables déclarées par des éléments var et script, enfants de l'élément vxml. Elles sont initialisées au chargement du document. Elles existent tant que le document est chargé. Elles ne sont visibles que dans ce document, à moins qu'il ne s'agisse d'un document racine d'application, auquel cas les variables sont visibles par les documents terminaux dans la portée de l'application seulement.
dialog Chaque dialogue (avec les éléments form ou menu) détermine une portée de dialogue qui existe dès lors que l'utilisateur visite le dialogue et qui est visible par les éléments qui le composent. La portée d'un dialogue recouvre les variables suivantes : celles déclarées par les éléments var et script enfants de l'élément form, celles des éléments de formulaire et les variables fictives des éléments de formulaire. Les éléments enfants var et script de l'élément form sont initialisés à la première visite du formulaire, contrairement aux éléments var dans le contenu exécutable qui sont initialisés à l'exécution de celui-ci.
(anonyme) Chaque élément block, filled et catch définit une nouvelle portée anonyme qui va contenir les variables déclarées dans l'élément en question.

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

L'écoulement de la portée depuis anonyme via dialog, document, application et session
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 :

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 :

Tableau 41 : Les attributs de l'élément throw
event L'événement suscité.
eventexpr Une expression ECMAScript donnant le nom de l'événement suscité.
message Une chaîne message fournissant des renseignements supplémentaires sur l'événement suscité. Pour les événements prédéfinis suscités par la plateforme, la teneur du message dépendra de la plateforme.
Le message est accessible comme valeur d'une variable dans la portée de l'élément catch, voir ci-dessous.
messageexpr Une expression ECMAScript donnant la chaîne message.

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 :

Tableau 42 : Les attributs de l'élément catch
event Le ou les événements à capturer. On peut définir une liste d'événements, séparés par des caractères espace, indiquant que l'élément catch capture tous les événements mentionnés dans la liste. Auquel cas, un compteur d'événement séparé (voir l'attribut count) est mis en place pour chaque événement. Si l'attribut n'est pas défini, alors tous les événements seront capturés.
count L'occurrence de l'événement (la valeur implicite est "1"). L'attribut count permet de gérer les différentes occurrences du même événement de manière distincte.

Chaque élément form, menu et élément de formulaire assure le compte de chaque événement survenant pendant qu'il est visité. Les compteurs d'événements de niveau élémentaire servent pour les événements suscités pendant la visite des éléments de formulaire individuels et pendant l'exécution des éléments filled contenus qui y sont contenus. Les compteurs de niveau formulaire et de niveau menu servent pour les événements suscités pendant l'initialisation du dialogue et pendant l'exécution des éléments filled de niveau formulaire.

Les compteurs d'événements de niveau formulaire et de niveau menu sont réinitialisés à chaque fois que l'on rentre dans l'élément form ou l'élément menu. Les compteurs d'événements de niveau formulaire et de niveau menu ne sont pas réinitialisés par l'élément clear.

Les compteurs d'événements de niveau élémentaire sont réinitialisés à chaque fois que l'on rentre dans l'élément form contenant l'élément en question. Ils sont également réinitialisés lorsqu'on réinitialise l'élément en question avec un élément clear. Les compteurs d'événements de niveau élémentaire ne sont pas réinitialisés quand on rentre dans l'élément en question sans avoir quitté l'élément form.

Les compteurs sont incrémentés par rapport au nom complet de l'événement et chaque préfixe correspondant au nom d'événement ; par exemple, une occurrence de l'évément event.foo.1 va incrémenter les compteurs de event.foo.1, plus ceux de event.foo et event.

cond Une expression dont la valeur, après conversion en un booléen, vaut "true" pour que l'événement puisse être capturé. La valeur implicite est "true".

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 :

Tableau 43 : Les attributs des abréviations de l'élément catch
count Le compte d'événements (comme pour l'élément catch).
cond Une condition facultative à tester afin de vérifier si l'événement est capturé par cet élément (comme pour l'élément catch décrit dans le chapitre 5.2.2). La valeur implicite est "true".

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.

Tableau 44 : Les gestionnaires de capture par défaut
Type d'événement Réponse audio Action
cancel non ne pas produire de nouvelle invite
error oui quitter l'interpréteur
exit non quitter l'interpréteur
help oui produire une nouvelle invite
noinput non produire une nouvelle invite
nomatch oui produire une nouvelle invite
maxspeechtimeout oui produire une nouvelle invite
connection.disconnect non quitter l'interpréteur
tous les autres oui quitter l'interpréteur

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 :

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 :

Tableau 45 : Les attributs de l'élément var
name Le nom de la variable qui contiendra le résultat. À la différence de l'attribut name de l'élément assign (voir le chapitre 5.3.2), cet attribut ne doit pas indiquer une variable avec un préfixe de portée (si une variable est définie avec un préfixe de portée, alors un événement error.semantic est suscité). La portée dans laquelle la variable est définie est déterminée à partir de la position dans le document où l'élément est déclaré.
expr La valeur initiale de la variable (optionnelle). En l'absence d'un attribut expr, la variable conserve sa valeur courante, le cas échéant. Les variables ont la valeur initiale ECMAScript "undefined" si elles n'ont pas été initialisées.

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 :

Tableau 46 : Les attributs de l'élément assign
name Le nom de la variable affectée. Comme indiqué dans le chapitre 5.1.2, la variable correspondante devra avoir été déclarée au préalable, sinon il sera suscité un événement error.semantic. Par défaut, la portée dans laquelle la la variable se résoud est la portée englobante la plus proche de l'élément actif courant. Pour lever toute ambiguïté, on peut préfixer le nom de la variable avec un nom de portée, comme décrit dans le chapitre 5.1.3.
expr La nouvelle valeur de la variable.

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 :

Tableau 47 : L'attribut de l'élément clear
namelist La liste des variables à réinitialiser ; elle peut comprendre des noms de variable autres que ceux d'éléments de formulaire. Si la liste de noms appelle une variable non déclarée, alors il sera suscité un événement error.semantic (voir le chapitre 5.1.1). En absence de l'attribut, toutes les variables des éléments de formulaire du formulaire courant sont effacées.

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 :

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 à :

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 :

Tableau 48 : Les attributs de l'élément goto
next L'adresse URI vers laquelle opérer la transition.
expr Une expression ECMAScript qui produit l'adresse URI.
nextitem Le nom de l'élément de formulaire suivant à visiter dans le formulaire courant.
expritem Une expression ECMAScript qui produit le nom de l'élément de formulaire suivant à visiter.
fetchaudio Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété fetchaudio.
fetchhint Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété documentfetchhint.
fetchtimeout Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété documentmaxage.
maxstale Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété documentmaxstale.

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 :

Tableau 49 : Les attributs de l'élément submit
next L'appel d'adresse URI.
expr Comme pour l'attribut next, hormis le fait que l'appel d'adresse URI est déterminé de manière dynamique en évaluant l'expression ECMAScript donnée.
namelist La liste des variables à soumettre. Par défaut, toutes les variables des éléments d'entrée nommés sont soumises. Quand on fournit un attribut namelist, il peut contenir des références de variables individuelles qui sont soumises avec la même qualification que celle utilisée dans la liste de nom. Les variables VoiceXML et ECMAScript déclarées peuvent être appelées. Si une variable non déclarée est appelée dans l'attribut namelist, alors un événement error.semantic est suscité (voir le (chapitre 5.1.1).
method La méthode de requête : "get" (la valeur implicite) ou "post".
enctype Le type de codage du média du document soumis (quand la valeur de l'attribut method est "post"). Sa valeur implicite est "application/x-www-form-urlencoded". Les interpréteurs doivent également gérer la valeur "multipart/form-data" mais peuvent prendre en charge d'autres types de codage.
fetchaudio Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété fetchaudio.
fetchhint Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété documentfetchhint.
fetchtimeout Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété documentmaxage.
maxstale Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété documentmaxstale.

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 :

Tableau 50 : Les attributs de l'élément exit
expr Une expression ECMAScript dont l'évaluation est la valeur renvoyée (par exemple, "0", "'oups !'" ou "champ1").
namelist Les noms des variables à renvoyer au contexte d'interprétation. Par défaut, aucune variable n'est renvoyée ; le contexte d'interprétation recevra un objet ECMAScript vide. Si une variable non déclarée est appelée dans l'attribut namelist, alors il sera suscité un événement error.semantic (voir le chapitre 5.1.1).

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 :

Tableau 51 : Les attributs de l'élément return
event Revient puis suscite cet événement.
eventexpr Revient puis suscite l'événement correspondant à l'évaluation de cette expression ECMAScript.
message Une chaîne message précisant le contexte de l'événement suscité. Le message est accessible sous forme de la valeur d'une variable dans la portée de l'élément de capture, voir le chapitre 5.2.2.
messageexpr Une expression ECMAScript dont l'évaluation correspond à la chaîne message.
namelist Les noms des variables à renvoyer au dialogue appelant. Par défaut, aucune variable n'est renvoyée ; l'appelant recevra un objet ECMAScript vide. Si une variable non déclarée est appelée dans l'attribut namelist, alors il sera suscité un événement error.semantic (voir le chapitre 5.1.1).

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 :

Tableau 52 : Les attributs de l'élément script
src L'adresse URI donnant l'emplacement du script, quand celui-ci est externe.
charset Le codage des caractères du script désigné par l'attribut src. Les codages UTF-8 et UTF-16 de la norme ISO/IEC 10646 doivent être gérés (commen dans le langage [XML]), d'autres codages, définis comme tels par [IANA], pouvant être gérés. La valeur implicite est "UTF-8".
fetchhint Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété scriptfetchhint.
fetchtimeout Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété fetchtimeout.
maxage Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété scriptmaxage.
maxstale Voir le chapitre 6.1. Sa valeur implicite est celle de la propriété scriptmaxstale.

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 :

Tableau 53 : Les attributs de l'élément log
label Une chaîne optionnelle qui peut servir, par exemple, à indiquer le but du journal.
expr Une expression ECMAScript optionnelle dont l'évaluation est une chaîne.

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 :

Tableau 54 : Les attributs de chargement
fetchtimeout L'intervalle de temps à attendre l'envoi du contenu avant de susciter un événement error.badfetch. La valeur est une désignation de temps (voir le chapitre 6.5). Si l'attribut n'est pas défini, une valeur dérivée de celle de la propriété fetchtimeout la plus interne sera utilisée.
fetchhint Définit le moment où le contexte d'interprétation devrait ramener le contenu du serveur : la valeur "prefetch" indique un téléchargement du fichier au moment du chargement de la page, tandis que la valeur "safe" indique un téléchargement quand c'est réellement nécessaire. Si l'attribut n'est pas défini, une valeur dérivée de celle de la propriété fetchhint concernée la plus interne sera utilisée.
maxage Indique que le document accepte d'utiliser un contenu dans la mesure où son âge n'est pas supérieur au temps indiqué en secondes (cf. la propriété max-age du protocole HTTP 1.1 [RFC2616]). Le document n'accepte pas d'utiliser un contenu périmé, à moins que l'attribut maxstale ne soit aussi défini. Si l'attribut n'est pas défini, une valeur dérivée de celle de la propriété maxage concernée la plus interne, si présente, sera utilisée.
maxstale Indique que le document accepte d'utiliser un contenu ayant dépassé sa date d'expiration (cf. la propriété max-age du protocole HTTP 1.1 [RFC2616]). Si l'attribut maxstale a reçu une valeur, alors le document accepte d'utiliser un contenu périmé mais pas plus du nombre de secondes indiqué. Si l'attribut n'est pas défini, une valeur dérivée de celle de la propriété maxstale concernée la plus interne, si présente, sera utilisée.

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 :

Tableau 55 : Un autre attribut du chargement
fetchaudio L'adresse URI du clip sonore à jouer pendant le chargement. Si l'attribut n'est pas défini, alors on utilise la valeur de la propriété fetchaudio, et si la valeur de cette dernière n'est pas fixée, aucun son ne sera joué pendant le chargement. Le chargement du clip sonore est régi par les propriétés audiofetchhint, audiomaxage, audiomaxstale et fetchtimeout en vigueur à l'instant du chargement. La lecture du clip sonore est régie par les propriétés fetchaudiodelay et fetchaudiominimum en vigueur à l'instant du chargement.

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 :

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

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 :

Tableau 56 : Les attributs de l'élément meta
name Le nom de la propriété de métadonnée.
content La valeur de la propriété de métadonnée.
http-equiv Le nom d'une en-tête de réponse HTTP.

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 :

Tableau 57 : Les propriétés de métadonnée Dublin Core recommandées
Creator La principale entité responsable de la fabrication du contenu de la ressource.
Rights Des informations concernant les droits détenus dans et sur la ressource.
Subject Le sujet du contenu de la ressource. En général, un sujet s'exprimera au travers de mots-clés, de phrases-clés ou de codes de classification. Le bon usage recommandé consiste à sélectionner des valeurs provenant d'un vocabulaire contrôlé ou d'un système de classification formel.

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 :

Tableau 58 : Les attributs de l'élément property
name Le nom de la propriété.
value La valeur de la propriété.

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 :

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] :

Tableau 59 : Les propriétés génériques des logiciels de reconnaissance vocale
confidencelevel Le niveau de fiabilité de la reconnaissance vocale : une valeur flottante dans l'intervalle "0.0" à "1.0". Les résultats sont rejetés (un événement nomatch est suscité) lorsque la valeur de la variable application.lastresult$.confidence est inférieure à ce seuil. Une valeur de "0.0" signifie qu'une fiabilité minimum est demandée pour une reconnaissance et, au contraire, une valeur de "1.1" une fiabilité maximum. La valeur est une désignation de nombre réel (voir le chapitre 6.5). La valeur implicite est de "0.5".
sensitivity Fixe le niveau de sensibilité. Une valeur de "1.0" signifie une haute sensibilité à une entrée silencieuse et, au contraire, une valeur de "0.0" la plus faible sensibilité au bruit. La valeur est une désignation de nombre réel (voir le chapitre 6.5). La valeur implicite est de "0.5".
speedvsaccuracy Un indice définissant l'équilibre souhaité entre vitesse et précision. Une valeur de "0.0" signifie la reconnaissance la plus rapide et une valeur de "1.0" la meilleure précision. La valeur est une désignation de nombre réel (voir le chapitre 6.5). La valeur implicite est de "0.5".
completetimeout

La longueur du silence demandé, suivant la parole de l'utilisateur, avant que le logiciel de reconnaissance vocale ne finalise un résultat (soit en l'acceptant, soit en suscitant un événement nomatch). On utilise la propriété completetimeout lorsque la parole est une correspondance complète à une grammaire active. Inversement, on utilise la propriété incompletetimeout lorsque la parole est une correspondance incomplète à une grammaire active.

Une valeur longue pour la propriété completetimeout repousse la production du résultat et, de ce fait, augmente le temps de réponse de l'ordinateur. Une valeur courte pour la propriété completetimeout peut entraîner la coupure inadéquate d'un énoncé. Les valeurs raisonnables pour le délai achevé se tiennent en général dans un intervalle de 0.3 à 1 seconde. La valeur est une désignation de temps (voir le chapitre 6.5). La valeur implicite dépend de la plateforme. Voir l'annexe D.

Bien que les plateformes doivent analyser la propriété completetimeout, elles ne sont pas obligées de mettre en œuvre son comportement. Les plateformes choisissant de ne pas mettre en œuvre le comportement de la propriété completetimeout doivent documenter et ajuster le comportement de la propriété incompletetimeout de la manière décrite ci-dessous.

incompletetimeout

La longueur du silence demandé, suivant la parole de l'utilisateur, avant que le logiciel de reconnaissance vocale ne finalise un résultat. La propriété incompletetimeout s'applique lorsque la parole précédent le silence est une correspondance incomplète sur toutes les grammaires actives. Auquel cas, une fois le délai déclenché, le résultat partiel est rejeté (avec un événement nomatch).

La propriété incompletetimeout s'applique aussi lorsque la parole précédent le silence est une correspondance complète à une grammaire active, mais quand il est possible de parler encore en correspondance à la grammaire. Par contraste, la propriété completetimeout s'utilise lorsque la parole est une correspondance complète à une grammaire active et qu'aucun mot en plus ne peut être dit.

Une valeur longue pour la propriété incompletetimeout retarde l'achèvement du résultat et, de ce fait, augmente le temps de réponse de l'ordinateur. Une valeur courte pour la propriété incompletetimeout peut entraîner la coupure inadéquate d'un énoncé.

La valeur de la propriété incompletetimeout est en général plus grande que celle de la propriété completetimeout afin de permettre aux utilisateurs une pause à mi-énoncé (par exemple, pour reprendre souffle). Voir l'annexe D.

Les plateformes choisissant de ne pas mettre en œuvre la propriété completetimeout (décrite précédemment) doivent utiliser la valeur maximum entre les propriétés completetimeout et incompletetimeout comme valeur de la propriété incompletetimeout.

La valeur est une désignation de temps (voir le chapitre 6.5).

maxspeechtimeout

La durée maximum de la parole de l'utilisateur. Si cette durée est écoulée avant que l'utilisateur ait fini de parler, alors l'événement maxspeechtimeout est suscité. La valeur est une désignation de temps (voir le chapitre 6.5). La durée implicite dépend de la plateforme.

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 :

Tableau 60 : Les propriétés génériques des logiciels de reconnaissance DTMF
interdigittimeout La valeur du délai entre les chiffres à utiliser dans la reconnaissance d'une entrée DTMF. La valeur est une désignation de temps (voir le chapitre 6.5). La valeur implicite dépend de la plateforme (voir l'annexe D.
termtimeout Le délai de terminaison à utiliser dans la reconnaissance d'une entrée DTMF. La valeur est une désignation de temps (voir le chapitre 6.5). La valeur implicite est "0s" (voir l'annexe D.
termchar Le caractère DTMF de terminaison dans une reconnaissance d'entrée DTMF. La valeur implicite est "#" (voir l'annexe D).

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 :

Tableau 61 : Les propriétés d'invite et de collecte
bargein L'attribut bargein à utiliser pour les invites. Fixer la valeur de cette propriété à "true" autorise implicitement les interruptions et, au contraire, fixer la valeur à "false" les interdit. La valeur implicite est "true".
bargeintype Fixe le type d'interruption : parole ("speech") ou mot-clé ("hotword"). La valeur par défaut est propre à la plateforme. Voir le chapitre 4.1.5.1.
timeout Le délai après lequel un événement noinput sera suscité par la plateforme. La valeur est une désignation de temps (voir le chapitre 6.5). La valeur par défaut dépend de la plateforme (voir l'annexe D).

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) :

Tableau 62 : Les propriétés de mise en place
audiofetchhint Indique à la plateforme si celle-ci peut ou non essayer d'optimiser l'interprétation d'un dialogue en préchargeant un fichier son. Sa valeur est soit "safe" pour signifier que le son ne doit être chargé qu'à la demande, jamais avant, soit "prefetch" pour permettre, mais sans obligation, à la plateforme de précharger le son. La valeur implicite est "prefetch".
audiomaxage Indique à la plateforme l'âge maximum acceptable en secondes des ressources audio mises en cache. La valeur par défaut est propre à la plateforme.
audiomaxstale Indique à la plateforme l'obsolescence maximum acceptable en secondes des ressources audio expirées mises en cache. La valeur par défaut est propre à la plateforme.
documentfetchhint Indique à la plateforme si les documents peuvent ou non être préchargés. La valeurs est soit "safe" (la valeur implicite), soit "prefetch".
documentmaxage Indique à la plateforme l'âge maximum acceptable en secondes des documents mis en cache. La valeur par défaut est propre à la plateforme.
documentmaxstale Indique à la plateforme l'obsolescence maximum acceptable en secondes des documents expirés mis en cache. La valeur par défaut est propre à la plateforme.
grammarfetchhint Indique à la plateforme si les grammaires peuvent ou non être préchargées. La valeur est soit "prefetch" (la valeur implicite), soit "safe".
grammarmaxage Indique à la plateforme l'âge maximum acceptable en secondes des grammaires mises en cache. La valeur par défaut est propre à la plateforme.
grammarmaxstale Indique à la plateforme l'obsolescence maximum acceptable en secondes des grammaires expirées mises en cache. La valeur par défaut est propre à la plateforme.
objectfetchhint Indique à la plateforme si le contenu de l'adresse URI de l'objet peut ou non être préchargé. Les valeurs sont "prefetch" (la valeur implicite) ou "safe".
objectmaxage Indique à la plateforme l'âge maximum acceptable en secondes des objets mis en cache. La valeur par défaut est propre à la plateforme.
objectmaxstale Indique à la plateforme l'obsolescence maximum acceptable en secondes des objets expirés mis en cache. La valeur par défaut est propre à la plateforme.
scriptfetchhint Indique à la plateforme si les scripts peuvent ou non être préchargés. Les valeurs sont "prefetch" (la valeur implicite) ou "safe".
scriptmaxage Indique à la plateforme l'âge maximum acceptable en secondes des scripts mis en cache. La valeur par défaut est propre à la plateforme.
scriptmaxstale Indique à la plateforme l'obsolescence maximum acceptable en secondes des scripts expirés mis en cache. La valeur par défaut est propre à la plateforme.
fetchaudio L'adresse URI du fichier son à jouer en attendant le chargement d'un document. Par défaut, aucun son n'est joué au cours des délais de chargement. La propriété fetchaudio ne s'applique pas au chargement des fichiers sons, des grammaires, des objets et des scripts. Le chargement du fichier son est régi par les propriétés audiofetchhint, audiomaxage, audiomaxstale et fetchtimeout en vigueur au moment du chargement. La lecture du fichier son est régie par les propriétés fetchaudiodelay et fetchaudiominimum en vigueur au moment du chargement.
fetchaudiodelay L'intervalle de temps à attendre au début d'un chargement avant de jouer le son de chargement indiqué par la propriété fetchaudio. La valeur est une désignation de temps (voir le chapitre 6.5). L'intervalle par défaut dépend de la plateforme (par exemple, "2s"). L'idée est la suivante : quand un délai de chargement est court, quelques secondes de silence peuvent être préférables à un bout de son de chargement qui est immédiatement coupé.
fetchaudiominimum L'intervalle minimum de temps pendant lequel jouer une source de son de chargement, une fois commencé, même si le résultat du chargement arrive dans le contretemps. La valeur est une désignation de temps (voir le chapitre 6.5). La valeur par défaut dépend de la plateforme (par exemple, "5s"). L'idée est la suivante : le son de chargement ne devrait pas être arrêté trop rapidement une fois que l'utilisateur a commencé à l'entendre.
fetchtimeout Le délai d'expiration des chargements. La valeur est une désignation de temps (voir le chapitre 6.5). La valeur par défaut dépend de la plateforme.

6.3.6 Les propriétés diverses

Tableau 63 : Les propriétés diverses
inputmodes Cette propriété détermine quelle modalité d'entrée utiliser. Les modes d'entrée activables : les tonalités DTMF ("dtmf") et la voix ("voice"). Sur les plateformes qui gèrent les deux modes, la valeur implicite de la propriété inputmodes est "dtmf voice". Pour désactiver la reconnaissance vocale, fixer la valeur de la propriété à "dtmf" et pour désactiver les tonalités DTMF, fixer sa valeur à "voice". Un usage de la propriété serait de désactiver la reconnaissance vocale en environnement bruyant. Un autre usage : désactiver la reconnaissance vocale afin de préserver les ressources qu'elle mobilise lorsqu'on sait que l'entrée sera toujours de type DTMF. Cette propriété ne contrôle pas l'activation des grammaires. Par exemple, les grammaires uniquement vocales peuvent être actives lorsque le mode d'entrée est restreint aux tonalités DTMF. Toutefois, ces grammaires ne seront pas sollicitées car la modalité d'entrée vocale est inopérante.
universals

Les plateformes peuvent, en option, fournir des grammaires de commande universelle propres, telles que des grammaires help, cancel ou exit, qui soient toujours actives (sauf en ce qui concerne les éléments d'entrée modale : voir le chapitre 3.1.4) et qui génèrent des événements propres.

Les applications de qualité production ont souvent besoin de définir leurs propres grammaires de commande universelle, par exemple, afin d'améliorer la portabilité de l'application ou de fournir une interface distincte. Elles indiquent alors les nouvelles grammaires de commande universelle au moyen d'éléments link et désactivent les grammaires par défaut au moyen de cette propriété. Les gestionnaires de capture par défaut ne sont pas affectés par cette propriété.

La valeur implicite, qui est "none", signifie que toutes les grammaires de commande universelle par défaut de la plateforme sont désactivées. La valeur "all" les active toutes. Les grammaires individuelles s'activent en listant leurs noms, séparés par des espaces (par exemple, "cancel exit help").

maxnbest Cette propriété contrôle la dimension maximale du tableau application.lastresult$ ; le tableau ne peut avoir une valeur supérieur à celle indiquée par cette propriété. Elle a une valeur minimale de "1". Sa valeur implicite est "1".

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 :

Tableau 64 : Les attributs de l'élément param
name Le nom à associer à ce paramètre quand l'objet ou le sous-dialogue est invoqué.
expr Une expression qui calcule la valeur associée au nom.
value Associe une valeur de chaîne littérale au nom.
valuetype L'une des valeurs "data" (la valeur implicite) ou "ref". Sert à indiquer à un objet si la valeur associée au nom se compose de données ou est une adresse URI. L'élément subdialog ne l'utilise pas car les valeurs sont toujours des données.
type Le type de média du résultat fourni par une adresse URI quand la valeur de l'attribut valuetype est "ref" ; son utilisation n'est pertinente que pour les éléments param dans les éléments object.

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 :

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 :

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.
}

Au cours de l'exécution de l'algorithme FIA, des événements peuvent être générés en plusieurs points. Ces événements sont traités différemment selon la phase qui est active.

Avant qu'un élément de formulaire ne soit sélectionné (c'est-à-dire, au cours des phases d'initialisation et de sélection), les événements sont générés au niveau du dialogue. Le gestionnaire de capture correspondant est localisé puis exécuté. Si la capture n'aboutit pas à une transition à partir du dialogue courant, alors l'exécution de l'algorithme FIA se terminera.

De même, les événements déclenchés après qu'un élément de formulaire a été sélectionné (c'est-à-dire, au cours des phases de collecte et de traitement) sont habituellement générés au niveau de l'élément de formulaire. Il y a une seule exception : les événements déclenchés par un élément filled de niveau dialogue sont générés au niveau dialogue. Le gestionnaire de capture correspondant est localisé puis exécuté. Si la capture n'aboutit pas à une transition, alors la boucle courante de l'algorithme FIA est terminée et la phase de sélection est réitérée.

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.

Diagramme de temporisation de la propriété timeout quand aucune entrée n'est fournie
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.

Diagramme de temporisation de la propriété interdigittimeout quand la grammaire n'est pas prête à terminer
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.

Diagramme de temporisation de la propriété interdigittimeout quand la grammaire est prête à terminer
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.

Diagramme de temporisation des propriétés termchar et interdigittimeout quand la grammaire peut terminer
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.

Diagramme de temporisation pour la propriété termchar vide quand la grammaire doit terminer
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.

Diagramme de temporisation de la propriété termchar non vide et de la propriété termtimeout quand la grammaire doit terminer
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).

Diagramme de temporisation de la propriété termchar non vide quand la grammaire doit terminer
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.

Diagramme de temporisation de la propriété timeout quand rien n'est 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.

Diagramme de temporisation de la propriété completetimeout avec une grammaire vocale reconnue
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é.

Diagramme de temporisation de la propriété incompletetimeout avec une grammaire vocale non reconnue
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 :

Tableau 65 : Les formats audio que les plateformes doivent gérer
Format audio Type de média
Raw (sans en-tête) 8kHz 8-bit mono mu-law [PCM] canal seul (G.711) audio/basic (selon [RFC1521])
Raw (sans en-tête) 8kHz 8-bit mono A-law [PCM] canal seul (G.711) audio/x-alaw-basic
WAV (en-tête RIFF) 8kHz 8-bit mono mu-law [PCM] canal seul. audio/x-wav
WAV (en-tête RIFF) 8kHz 8-bit mono A-law [PCM] canal seul. audio/x-wav

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 :

Annexe H : L'accessibilité

La voix est au centre des applications VoiceXML, mais n'en est pas la limite. Alors que la parole et l'écoute seront les techniques les plus couramment utilisées dans la plupart des circonstances et pour la plupart des utilisateurs en interaction avec des applications VoiceXML, certains utilisateurs pourront être temporairement (ou de façon permanente) incapables de parler et/ou d'écouter. Des personnes invalides, notamment celles ayant des difficultés pour parler et/ou entendre, peuvent avoir besoin d'interagir autrement avec les applications VoiceXML :

  1. Les utilisateurs sourds peuvent lire un texte sur un écran ou (s'ils sont aussi aveugles) lire un texte en Braille au toucher. Afin de prendre en compte les appareils spéciaux employés par les personnes ayant une déficience de la vue et/ou de l'ouïe, les développeurs sont encouragés à fournir un équivalent textuel de chaque invite sonore à l'intérieur de l'élément audio. Par exemple :
    <audio src="bienvenue.wav">Bienvenue</audio>
    
    Cette déclaration ferait en sorte de jouer le fichier son bienvenue.wav. Toutefois, si le contexte d'interprétation VoiceXML avait détecté que l'utilisateur voyait l'interaction sur un écran ou touchait un dispositif de sortie Braille, alors le texte Bienvenue serait restitué par l'écran ou le dispositif de sortie Braille.
  2. Les utilisateurs déficients de la parole peuvent saisir des séquences codées qui sont converties en texte alphabétique avant d'alimenter la plateforme VoiceXML. Un dispositif matériel spécial accouplé à un téléphone pourrait convertir, par exemple, les touches d'un clavier QWERTY en un texte alphabétique. Cette conversion pourrait également être effectuée par un logiciel traduisant les séquences de tonalités DTMF d'un clavier téléphonique à douze touches en un texte alphabétique.

La mise en place de voies alternatives pour la livraison des informations et pour les entrées d'utilisateur est au centre de toutes les technologies du W3C destinées à être utilisées par les personnes. Bien qu'elles aient été conçues à l'origine pour rendre accessible un contenu à l'écran, les directives pour l'accessibilité suivantes, publiées par l'Initiative pour l'accessibilité du Web (WAI), s'appliquent aussi au langage VoiceXML :.

Voici d'autres directives permettant aux personnes invalides d'accéder aux applications VoiceXML :

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

Les éléments obsolètes

Les éléments modifiés de manière incompatible

Les éléments modifiés

Les éclaircissements

Divers

Annexe K : La réutilisabilité

K.1 Les composants de dialogue réutilisables

Définition : Un fragment d'application conditionné, destiné à être invoqué par des applications arbitraires ou par d'autres composants de dialogue réutilisables. Un composant de dialogue réutilisable (RDC) encapsule le code d'une interaction avec l'appelant.

Les composants de dialogue réutilisables offrent des fonctionnalités prêt-à-servir pré-empaquetées qui permettent aux développeurs de construire des applications rapidement, en fournissant, par défaut, un paramétrage et un comportement normalisés. Ils isolent les développeurs des complexités associées à la construction d'un dialogue vocal fiable, par exemple, l'interprétation du score de fiabilité, les mécanismes de récupération des erreurs, la génération des invites, etc. Le développeur peut, si nécessaire, personnaliser ce comportement afin de fournir les invites, le vocabulaire, le paramétrage des nouvelles tentatives, etc., qui soient propres à l'application.

Dans cette version du langage VoiceXML, les seuls mécanismes d'appel de composants authentiquement réutilisables sont représentés par les éléments subdialog et object. Les composants appelés de cette façon obéissent à un modèle similaire aux sous-routines des langages de programmation : le composant est configuré par un ensemble bien déterminé de paramètres qui lui sont passés, le composant a une interaction contrainte relativement à l'application appelante, le composant renvoie un résultat bien défini et le contrôle revient automatiquement au point d'où le composant a été appelé. Le modèle réunit tous les avantages significatifs de modularité, de réentrée et de facilité de réemploi offerts par les sous-routines. Sur les deux types de composant, seuls les composants subdialog sont assurés d'être aussi portables que le langage VoiceXML lui-même. Par contre, les composants object peuvent empaqueter des fonctionnalités réutilisables évoluées qui n'ont pas encore été introduites dans la norme.

K.2 Les gabarits et les échantillons

Bien que les composants de dialogue réutilisables possèdent les avantages de modularité, de réentrée et de facilité de réemploi décrits ci-dessus, ces composants ont pour inconvénient de demander une conception très soigneuse, en gardant une vue sur la réutilisation, et même pour la conception la plus attentionnée, le développeur de l'application est susceptible de rencontrer des situations pour lesquelles le composant ne pourra pas être facilement configuré pour tenir les conditions requises par l'application. En outre, alors que l'interaction contrainte d'un composant avec son environnement d'appel est susceptible de permettre à un concepteur de créer un composant fonctionnant de manière prévisible dans des environnements disparates, elle peut aussi faire que l'interaction de l'utilisateur avec le composant apparaisse désolidarisée du reste de l'application.

Auxquels cas, le développeur de l'application peut vouloir réutiliser un code source VoiceXML sous forme d'échantillons et de gabarits, les échantillons étant conçus pour être facilement personnalisables. Un tel code s'adaptera et s'intégrera plus aisément à une application particulière, aux dépends de la modularité et de la réentrée.

On peut créer ces gabarits et ces échantillons en séparant le code VoiceXML intéressant du dialogue principal, puis en distribuant ce code par copies à utiliser dans d'autres dialogues. Cette forme de réutilisabilité permet à l'utilisateur du code VoiceXML copié de le modifier au besoin et de continuer à utiliser indéfiniment la version modifiée.

Le langage VoiceXML encourage cette forme de réutilisabilité en préservant la séparation d'état entre les éléments form. De ce point de vue, les langages VoiceXML et [HTML] sont similaires. Un tableau HTML peut se copier d'une page HTML à une autre, parce que le tableau peut s'afficher indépendamment du contexte précédent ou suivant l'élément <table>.

Même si cette approche peut sacrifier les possibilités de paramétrage, la modularité et le suivi, elle a l'avantage d'être simple, rapide et éminemment personnalisable.

Annexe L : Remerciements

Cette spécification du W3C est fondée sur VoiceXML 1.0, soumis par le Forum VoiceXML en mai 2000. Les auteurs du Forum VoiceXML étaient : Linda Boyer, IBM ; Peter Danielsen, Lucent Technologies ; Jim Ferrans, Motorola ; Gerald Karam, AT&T ; David Ladd, Motorola ; Bruce Lucas, IBM ; Kenneth Rehor, Lucent Technologies.

Cette version a été rédigée par les participants du groupe de travaile Navigateur vocal du W3C. Les personnes suivantes ont contribué notablement à la rédaction de cette spécification :

Le groupe de travail voudrait remercier Dave Raggett et Jim Larson pour leur inestimable soutien.

Annexe M : Références

M.1. Les références normatives

[CSS2]
La spécification des feuilles de style en cascade (CSS2), Bos et al. Recommandation du W3C, mai 1998
Voir http://www.w3.org/TR/REC-CSS2/
[ECMASCRIPT]
La norme ECMA-262 : spécification du langage ECMAScript, Standard ECMA-262, décembre 1999.
Voir http://www.ecma-international.org/publications/standards/Ecma-262.htm
[RFC1521]
MIME (Multipurpose Internet Mail Extensions) 1ere partie : les mécanismes de définition et de description du format des corps des message Internet, IETF RFC 1521, 1993
Voir http://www.ietf.org/rfc/rfc1521.txt
[RFC2396]
Les identificateurs de ressource uniformes (URI) : la syntaxe générique, IETF RFC 2396, 1998.
Voir http://www.ietf.org/rfc/rfc2396.txt
[RFC2616]
Le protocole de transfert hypertexte - HTTP/1.1, IETF RFC 2616, 1999.
Voir http://www.ietf.org/rfc/rfc2616.txt
[RFC2806]
Les adresse URL pour les appels téléphoniques, IETF RFC 2806, 2000.
Voir http://www.ietf.org/rfc/rfc2806.txt
[RFC3066]
Les étiquettes pour l'identification des langues, IETF RFC 3066, 2001.
Remarquez que le langage [XML] a adopté RFC3066 au travers d'un errata en date du 2001-02-22. Le document RFC3066 remplace le document [RFC1766].
Voir http://www.ietf.org/rfc/rfc3066.txt
[SCHEMA1]
Le schéma XML 1ere partie : les structures, Thompson et al. Recommandation du W3C, mai 2001.
Voir http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
[SRGS]
La spécification des grammaires de reconnaissance vocale version 1.0, Hunt et McGlashan. Recommandation proposée du W3C, décembre 2003.
Voir http://www.w3.org/TR/2003/PR-speech-grammar-20031218/
[SSML]
Le langage de balisage de la synthèse vocale version 1.0, Burnett, Walker et Hunt. Recommandation candidate du W3C, décembre 2003.
Voir http://www.w3.org/TR/2003/CR-speech-synthesis-20031218/
[UNICODE]
Le standard Unicode, The Unicode Consortium.
Voir http://www.unicode.org/unicode/standard/standard.html
[XML]
Le langage de balisage extensible (XML) 1.0, Bray et al. Recommandation du W3C.
Voir http://www.w3.org/TR/2000/REC-xml-20001006
[XML-BASE]
XML Base, J. Marsh, rédacteur, Recommandation du W3C, juin 2001.
Voir http://www.w3.org/TR/2001/REC-xmlbase-20010627/.
[XMLNAMES]
Les espaces de nommage dans XML, Bray et al. Recommandation du W3C, janvier 1999.
Voir http://www.w3.org/TR/1999/REC-xml-names-19990114/

M.2. Les références informatives

[ATAGIO]
Les directives pour l'accessibilité des outils de création 1.0, Treviranus et al. Recommandation du W3C, février 2000.
Voir http://www.w3.org/TR/2000/REC-ATAG10-20000203/
[DC]
L'initiative Dublin Core pour les métadonnées, un modèle de description de contenu simple pour les ressources électroniques.
Voir http://dublincore.org/
[HTML]
La spécification HTML 4.01, Dave Raggett et al. Recommandation du W3C, décembre 1999.
Voir http://www.w3.org/TR/1999/REC-html401-19991224/
[IANA]
Les jeux de caractères IANA, IANA.
Voir http://www.iana.org/assignments/character-sets
[ISO4217]
ISO 4217:2001 Codes pour la représentation des monnaies et des fonds, ISO, 2001
Voir http://www.iso.ch/
[JSAPI]
Java Speech API, Sun Microsystems, Inc.
Voir http://java.sun.com/products/java-media/speech/index.jsp
[JSGF]
JSpeech Grammar Format, Andrew Hunt, Note du W3C, juin 2000.
Voir http://www.w3.org/TR/2000/NOTE-jsgf-20000605/
[NLSML]
Le langage de balisage sémantique des langues naturelles du cadre des interfaces vocales, Deborah A. Dahl. Brouillon du W3C, novembre 2000
Voir http://www.w3.org/TR/2000/WD-nl-spec-20001120/
[RDF-SYNTAX]
La spécification du modèle et de la syntaxe du cadre de description des ressources (RDF), Ora Lassila et Ralph R.Swick. Recommandation du W3C, février 1999.
Voir http://www.w3.org/TR/REC-rdf-syntax/
[RDF-SCHEMA]
La spécification du schéma du cadre de description des ressources (RDF) 1.0, Dan Brickley et R.V. Guha. Recommandation candidate du W3C, mars 2000.
Voir http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
[RFC1766]
Les étiquettes pour l'identification des langues, IETF RFC 1766, 1995
Remarquez que le langage [XML] a adopté RFC3066 au travers d'un errata en date du 2001-02-22. Le document [RFC3066] remplace le document RFC1766.
Voir http://www.ietf.org/rfc/rfc1766.txt
[RFC2119]
Les mots-clés à utiliser dans les documents RFC pour indiquer les niveaux d'obligation, IETF RFC 2119, 1997.
Voir http://www.ietf.org/rfc/rfc2119.txt
[RFC2361]
Les registres des codecs WAVE et AVI, IETF RFC 2361, 1998.
Voir http://www.ietf.org/rfc/rfc2361.txt
[SISR]
L'interprétation sémantique de la reconnaissance vocale, Luc Van Tichelen. Brouillon du W3C, avril 2003.
Voir http://www.w3.org/TR/2003/WD-semantic-interpretation-20030401/
[UAAGIO]
Les directives pour l'accessibilité des agents utilisateurs 1.0, Jacobs et al. Recommandation proposée du W3C, octobre 2002.
Voir http://www.w3.org/TR/2002/PR-UAAG10-20021016/
[VOICEXML-1.0]
Le langage de balisage extensible de la voix 1.0, Boyer et al, Note du W3C, mai 2000.
Voir http://www.w3.org/TR/2000/NOTE-voicexml-20000505/
[WAI-WEBCONTENT]
Les directives pour l'accessibilité du contenu Web 1.0, Chisholm et al. Recommandation du W3C, mai 1999
Voir http://www.w3.org/TR/WAI-WEBCONTENT/
[XAG]
Les directives pour l'accessibilité du langage XML, Dardailler et al. Brouillon du W3C, octobre 2002
Voir http://www.w3.org/TR/xag.html

Annexe N : Le type de média et le suffixe de fichier

Le groupe de travail Navigateur vocal du W3C a déposé, auprès de l'IETF, une demande d'enregistrement pour un type de média du langage VoiceXML. Le type de média demandé est : application/voicexml+xml.

Le groupe de travail Navigateur vocal du W3C a adopté la convention d'utiliser le suffixe de nom de fichier .vxml pour les documents VoiceXML.

Annexe O : La définition du schéma XML du langage VoiceXML

Cette section est normative.

La définition du schéma XML du langage VoiceXML se trouve à : http://www.w3.org/TR/voicexml20/vxml.xsd.

Le schéma VoiceXML dépend d'autres schémas définis dans l'espace de nommage VoiceXML :

Le jeu complet des schémas du cadre des interfaces vocales exigés pour VoiceXML 2.0 est disponible à : http://www.w3.org/TR/2004/REC-voicexml20-20040316/vxml-schema.zip.

Annexe P : Les types des grammaires intégrées

L'attribut type de l'élément field dans le chapitre 2.3.1 sert à indiquer une grammaire intégrée de l'un des types fondamentaux. La prise en charge par la plateforme des grammaires intégrées fondamentales est optionnelle. Si une plateforme gère les types intégrés, alors elle doit suivre la description donnée dans cette annexe, d'aussi prêt que possible, y compris tous les grammaires intégrées d'une langue donnée.

Chaque type intégré suit une convention pour le format de la valeur renvoyée. Ces valeurs sont indépendantes de la langue et de l'implémentation. Le type renvoyé pour les champs intégrés est une chaîne, sauf pour le type de champ boolean. Pour accéder au résultat réel de la reconnaissance, l'auteur peut appeler la variable fictive nom$.utterance de l'élément field. Autrement, le développeur peut accéder au tableau application.lastresult$, dans lequel la variable application.lastresult$.interpretation a la même valeur que la variable application.lastresult$.utterance.

Les types intégrés sont définis de telle façon qu'un développeur d'application VoiceXML peut compter sur une certaine cohérence de l'entrée d'utilisateur à travers les implémentations. Cela permet aux messages d'assistance et à d'autres invites d'être indépendants de la plateforme de plusieurs façons. Par exemple, la grammaire de type boolean devrait admettre au moins les réponses oui et non en français, mais chaque implémentation est libre d'ajouter d'autres choix comme ouais et nan.

Au cas où une application exige un comportement particulier ou un comportement différent de celui défini pour un type intégré, elle devrait utiliser une grammaire de champ explicite. Voici des circonstances dans lesquelles une application doit fournir une grammaire de champ explicite, pour assurer la portabilité de l'application avec une interface d'utilisateur cohérente :

Tous les types intégrés doivent gérer à la fois les entrées vocales et DTMF.

L'ensemble des entrées prononcées acceptées pour chaque type intégré dépend de la plateforme, et il variera selon la langue.

La valeur renvoyée par un type intégré peut être lue au moyen de l'élément say-as. Le langage VoiceXML augmente l'élément say-as dans [SSML] en lui ajoutant les valeurs de l'attribut interpret-as, qui correspondent à chaque type intégré. Ces valeurs prennent la forme vxml:type, où type est un type intégré. La restitution précise des types intégrés est propre à la plateforme, et elle variera selon la langue.

Les types intégrés sont les suivants :

Tableau 66 : Les types intégrés
boolean Les entrées comprennent les phrases affirmatives et négatives appropriées dans la langue courante. DTMF 1 est affirmatif tandis que DTMF 0 est négatif. Le résultat est la valeur ECMAScript "true" pour l'affirmatif et "false" pour le négatif. La valeur sera soumise en tant que chaîne true ou false. Si la valeur de champ est utilisée ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:boolean", elle sera prononcée comme une affirmation, ou une négation, appropriée dans la langue courante.
date Les entrées prononcées valides comprennent les phrases qui indiquent une date, incluant le jour, le mois et l'année. Les entrées DTMF se composent de quatre chiffres pour l'année, suivis de deux chiffres pour le mois et de deux chiffres pour le jour. Le résultant est une chaîne de longueur fixe de format aaaammjj, par exemple, 20000704. Si l'année n'est pas indiquée, le composant yyyy est renvoyé comme étant ????, si c'est le mois, le composant mm est renvoyé comme ??, et si c'est le jour, jj est renvoyé comme ??. Si la valeur est utilisée ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:date", elle sera prononcée comme une date appropriée dans la langue courante.
digits Les entrées prononcées ou DTMF valides comprennent un ou plusieurs chiffres, de 0 à 9. Le résultat est une chaîne de chiffres. Si le résultat est utilisé ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:digits", il sera prononcé comme une séquence de chiffres appropriée dans la langue courante. Un utilisateur peut dire, par exemple, un neuf deux sept, mais pas dix-neuf cent vingt-sept. Une plateforme peut gérer des constructions comme deux (deux fois cinq) huit.
currency Les entrées prononcées valides comprennent les phrases qui indiquent une quantité monétaire. Pour une entrée DTMF, l'étoile * fera office de point décimal. Le résultat est une chaîne dont le format est UUUmm.nn, où UUU représente les trois caractères de l'indicateur monétaire, selon le standard ISO 4217 [ISO4217], ou mm.nn, si l'utilisateur ne dit pas l'unité monétaire ou si celle-ci ne peut pas être déterminée avec fiabilité (par exemple, dollar et peso sont ambigus). Si le champ est utilisé ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:currency", il sera prononcé comme une quantité monétaire appropriée dans la langue courante.
number Les entrées prononcées valides comprennent les phrases qui indiquent des nombres, tel que cent vingt-sept, ou cinq point trois. Les entrées DTMF valides comprennent les nombres positifs saisis en utilisant les touches de chiffres et l'étoile * pour représenter le séparateur décimal. Le résultat est une chaîne de chiffres, de 0 à 9, qui peut inclure, en option, un point décimal (.) et/ou un signe plus + ou -. Le langage ECMAScript convertit automatiquement les chaînes résultats en valeurs numériques utilisées dans les expressions numériques. Le résultat ne doit pas contenir de zéro de tête (ce qui le ferait interpréter comme un nombre octal par ECMAScript). Si le champ est utilisé ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:number", il sera prononcé comme un nombre approprié dans la langue courante.
phone Les entrées prononcées valides comprennent les phrases qui indiquent un numéro de téléphone. L'étoile DTMF * représente x. Le résultat est une chaîne contenant un numéro de téléphone composé d'une chaîne de chiffres contenant, en option, le caractère x, lequel indique un numéro de téléphone avec une extension. Pour l'Amérique du Nord, on aurait, par exemple, 8005551234x789. Si le champ est utilisé ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:phone", il sera prononcé comme un numéro de téléphone approprié dans la langue courante.
time Les entrées prononcées valides comprennent les phrases qui indiquent une heure, incluant les heures et les minutes. Le résultat est une chaîne composée de cinq caractères dans le format hhmmx, où x prend la valeur a pour AM, p pour PM, h pour une heure sur 24 heures ou ? pour indiquer une heure ambiguë. Il peut y avoir une entrée via DTMF. En l'absence de convention DTMF pour indiquer AM/PM, le résultat se terminera toujours par h ou ?. Si le champ est utilisé ensuite dans un élément say-as avec un attribut interpret-as fixé à "vxml:time", il sera prononcé comme une heure appropriée dans la langue courante.

Un exemple d'élément field avec un type de grammaire intégrée :

<field name="repas_dietetique" type="boolean">

  <prompt>
    Voulez-vous un repas diététique sur ce vol ?
  </prompt>
  <help>
    Diététique signifie moins de 10 grammes de lipides,
    et moins de 250 calories.
  </help>
  <filled>
    <prompt>
      J'ai entendu <emphasis><say-as interpret-as="vxml:boolean">
      <value expr="repas_dietetique"/></say-as></emphasis>.
    </prompt>
  </filled>
</field>

Dans cet exemple, le type boolean indique que les entrées auront la forme d'affirmations ou de négations diverses. La valeur réellement placée dans le champ sera soit "true", soit "false". Le champ sera lu en se servant de la réponse appropriée, affirmative ou négative, faite dans les invites.

Dans l'exemple suivant, le type digits indique que l'entrée prendra la forme de chiffres prononcés ou saisis. Le résultat est stocké comme une chaîne et restitué comme chiffres en utilisant un élément say-as dont l'attribut interpret-as a la valeur "vxml:digits", c'est-à-dire un deux trois, et non pas cent vingt-trois. L'action filled teste le champ afin de vérifier s'il a 12 chiffres. Dans le cas contraire, l'utilisateur entend le message d'erreur :

<field name="ticket_num" type="digits">
  <prompt>
     Lisez les 12 chiffres du numéro de votre ticket.
  </prompt>
  <help>Le nombre à 12 chiffres se trouve en bas à gauche.</help>
  <filled>
     <if cond="num_ticket.length != 12">
       <prompt>
         Désolé, je n'ai pas entendu les 12 chiffres.
       </prompt>
       <assign name="num_ticket" expr="undefined"/>
     <else/>
       <prompt>J'ai entendu <say-as interpret-as="vxml:digits"> 
         <value expr="num_ticket"/></say-as>
       </prompt>
     </if>
  </filled>
</field>

Les grammaires intégrées des types boolean et digits peuvent se paramétrer. On le fait en appelant explicitement les grammaires intégrées au moyen d'un système d'adresse URI builtin propre à la plateforme et d'une syntaxe de requête de style URI de la forme type?paramètre=valeur, dans l'attribut src d'un élément grammar ou bien dans l'attribut type d'un élément field, par exemple :

<grammar src="builtin:dtmf/boolean?y=7;n=9"/>

<field type="boolean?y=7;n=9">
   <prompt>
     Si c'est exact, dites oui, ou pressez sept, sinon dites non, ou pressez neuf.
  </prompt>
</field>

<field type="digits?minlength=3;maxlength=5">
   <prompt>Veuillez saisir votre code d'authentification</prompt>
</field>

Dans lequel, l'élément grammar paramètre la grammaire DTMF intégrée, le premier élément field paramètre la grammaire DTMF intégrée (la grammaire vocale sera activée normalement) et le second élément field paramètre à la fois les grammaires intégrées vocale et DTMF. Les paramètres indéfinis pour un type de grammaire donné seront ignorés, par exemple, builtin:grammar/boolean?y=7.

Les grammaires intégrées de type digits et boolean peuvent se paramétrer comme suit :

Tableau 67 : Le paramétrage des grammaires de type digit et boolean
digits?minlength=n Une chaîne d'au moins n chiffres. Applicable aux grammaires vocale et DTMF. Si minlength entre en conflit avec l'attribut length ou bien l'attribut maxlength, alors un événement error.badfetch est suscité.
digits?maxlength=n Une chaîne d'au plus n chiffres. Applicable aux grammaires vocale et DTMF. Si maxlenght entre en conflit avec l'attribut length ou bien l'attribut minlength, alors un événement error.badfetch est suscité.
digits?length=n Une chaîne d'exactement n chiffres. Applicable aux grammaires vocale et DTMF. Si length entre en conflit avec l'attribut minlength ou bien l'attribut maxlength, alors un événement error.badfetch est suscité.
boolean?y=d Une grammaire qui traite la touche d comme une réponse affirmative. Applicable seulement à la grammaire DTMF.
boolean?n=d Une grammaire qui traite la touche d comme une réponse négative. Applicable seulement à la grammaire DTMF.

Remarquez que l'on peut indiquer plusieurs paramètres, séparés par un caractère ;, comme illustré précédemment. Lorsqu'un élément grammar, avec un attribut mode fixé à "voice" (la valeur implicite), est défini dans un élément field, la grammaire s'ajoute à la grammaire vocale par défaut impliquée par l'attribut type de l'élément field. De la même façon, lorsqu'un élément grammar avec un attribut mode fixé à "dtmf" est défini dans un élément field, la grammaire s'ajoute à la grammaire DTMF par défaut de l'élément field.