Source: http://yoyodesign.org/doc/w3c/speech-grammar-20040316/
Timestamp: 2017-09-26 21:43:36+00:00

Document:
Recommandation du W3C du 16 mars 2004
Veuillez consulter l'errata de ce document, lequel peut inclure des corrections normatives.
Voir également d'éventuelles traductions.
Ce document définit une syntaxe pour représenter les grammaires à utiliser en reconnaissance vocale, afin que les développeurs puissent définir les mots et combinaisons de mots que doit écouter un logiciel de reconnaissance vocale. La syntaxe du format de grammaire se présente sous deux formes : une forme BNF augmentée (ABNF) et une forme XML. La spécification établit une correspondance entre les deux représentations qui permet des transformations automatiques entre les formes.
Cette section 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 a été passé en revue par les membres du W3C et les tiers intéressés, et il 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 à en promouvoir le large déploiement. Cela participe à la fonctionnalité et l'interopérabilité du Web.
Cette spécification fait partie du cadre Speech Interface Framework du W3C et elle a été développée au sein de l'activité Voice Browser du W3C (cf. la déclaration d'activité) par les participants au groupe de travail Voice Browser (réservé aux membres du W3C).
La conception de la spécification des grammaires de reconnaissance vocale (SRGS) version 1.0 a fait l'objet d'un examen approfondi (cf. la présentation des commentaires) et elle satisfait aux exigences techniques du groupe de travail. Une liste des mises en œuvre est incluse dans le rapport de mise en œuvre de SRGS 1.0, ainsi que la suite de tests associée.
Toutes les remarques sont bienvenues sur la liste de diffusion www-voice@w3.org (archives). Cf. le guide d'utilisation des listes de diffusion et archives du W3C.
Le W3C tient une liste des divulgations de brevets liées à ces travaux.
1.1 Les processeurs grammaticaux et les agents utilisateurs
1.2 Le domaine d'application
1.3 Les conversions de grammaire
1.4 L'interprétation sémantique
1.5 Les grammaires incorporées
1.6 La terminologie
2. Les extensions de règles
2.1 Les atomes
2.2 Les appels de règles
2.2.1 Les appels locaux
2.2.2 Les appels externes par adresse URI
2.2.3 Les règles spéciales
2.2.4 L'appel des documents de grammaire N-Gram
2.3 Les séquences et l'encapsulation
2.4 Les choix
2.4.1 Les poids
2.5 Les répétitions
2.5.1 Les probabilités de répétition
2.7 La langue
2.8 L'ordre de priorité
3. Les définitions de règles
3.1 La définition des règles élémentaires
3.2 La portée des définitions de règles
3.3 Exemples de phrases
4. Les documents de grammaire
4.1 Les déclarations d'en-tête des grammaires
4.2 L'en-tête auto-identifiante ABNF
4.3 Le prologue et l'élément racine de la forme XML
4.4 Le codage de caractères
4.5 La langue
4.6 Le mode
4.7 La règle racine
4.8 Le format des balises
4.9 L'adresse URI de base
4.9.1 La résolution des adresses URI relatives
4.10 Le lexique de prononciation
4.11 Les métadonnées
4.11.1 Les déclarations meta et http-equiv
4.11.2 Les métadonnées XML (XML uniquement)
4.12 Les balises
4.13 Les commentaires
4.14 La récupération de la grammaire
4.15 Les mots-clés ABNF
5.1 Les fragments de grammaire de forme XML conformes
5.2 Les documents de grammaire de forme XML autonomes conformes
5.3 L'utilisation des grammaires de forme XML avec d'autres espaces de nommage
5.4 Les processeurs grammaticaux de forme XML conformes
5.5 Les documents de grammaire de forme ABNF autonomes conformes
5.6 Les processeurs grammaticaux de forme ABNF conformes
5.7 Les processeurs grammaticaux de forme ABNF/XML conformes
5.8 Les agents utilisateurs conformes
Annexe A. Références
A.2 Les références informatives
Annexe B. La définition DTD des grammaires de forme XML (informatif)
Annexe C. La définition XML Schema des grammaires de forme XML (normatif)
Annexe D. La syntaxe formelle des grammaires de forme ABNF (normatif)
Annexe E. Les grammaires DTMF (normatif)
Annexe F. Une feuille de style XSLT pour convertir les grammaires de forme XML en ABNF (informatif)
Annexe G. Les types de médias et les suffixes de fichiers (informatif)
Annexe H. La structure d'analyse logique (informatif)
H.1 La terminologie et la notation
H.2 L'analyse des appels de règles
H.3 La récursion
Annexe I. Les fonctionnalités à l'étude pour les versions futures (informatif)
Annexe J. Exemples de grammaires de forme ABNF et de forme XML (informatif)
J.1 Exemples simples (en français)
J.2 Exemples avec références croisées (en français)
J.3 Exemples en coréen
J.4 Exemples en chinois
J.5 Exemples en suédois
Ce document définit la syntaxe de représentation des grammaires. Les grammaires sont destinées aux logiciels de reconnaissance vocale et autres processeurs grammaticaux, pour que les développeurs puissent définir les mots ou combinaisons de mots que doit écouter le logiciel de reconnaissance vocale.
La syntaxe du format de grammaire se présente sous deux formes : une forme BNF augmentée (ABNF) et une forme XML. La spécification assure une correspondance sémantique des deux représentations afin de permettre des transformations automatiques entre ces formes.
La syntaxe BNF augmentée (ABNF) : c'est une représentation en texte ordinaire (non-XML) similaire à la grammaire BNF traditionnelle et à beaucoup de représentations apparentées BNF existantes couramment utilisées dans le domaine de la reconnaissance vocale, y compris le format JSpeech Grammar Format [JSGF] dont découle cette spécification. Il ne faut pas confondre les formats BNF augmenté et BNF étendu (EBNF), ce dernier format servant pour les définitions DTD des langages XML et SGML.
La syntaxe XML : elles utilise des éléments XML pour représenter les structures grammaticales et adapte des conceptions issues de la grammaire PipeBeach de TalkML [TALKML] et d'une variante XML expérimentale du format JSpeech Grammar Format [JSGF].
Les formes ABNF et XML ont toutes deux la puissance d'expression d'une grammaire indépendante du contexte (CFG). Un processeur grammatical sans prise en charge des grammaires récursives a la puissance d'expression d'une machine à états finis (FSM) ou d'un langage d'expressions rationnelles. Cf. par exemple le document [HU79] pour des définitions des grammaires CFG et FSM, des expressions rationnelles ou d'une autre théorie de langage informatique formel. Cette forme d'expression de langage suffit à la grande majorité des applications de reconnaissance vocale.
Ce standard du W3C est connu sous l'appellation La spécification des grammaires de reconnaissance vocale , et il prend modèle sur la spécification du format JSpeech Grammar Format [JSGF], appartenant à la société Sun Microsystems, Inc., California, U.S.A.
Un processeur grammatical est tout dispositif acceptant des grammaires en entrée, comme cette spécification les décrit.
Un agent utilisateur est un processeur grammatical qui accepte une entrée d'utilisateur et la compare à une grammaire afin de produire un résultat de reconnaissance représentant l'entrée détectée.
Comme l'indique le titre de la spécification, les logiciels de reconnaissance vocale constituent une classe de processeurs grammaticaux importante. Une autre classe de processeurs grammaticaux anticipée par cette spécification est celle des détecteurs multifréquences à deux tonalités (DTMF). Le mode (ou les modes) de grammaire qu'un agent utilisateur peut traiter détermine le type d'entrée qu'il accepte, par exemple, une entrée vocale pour les grammaires en mode "voice" et une entrée DTMF pour les grammaires en mode "dtmf".
Pour la simplicité, tout au long de ce document, les références aux logiciels de reconnaissance vocale s'appliqueront aux autres types de processeurs grammaticaux, sauf indication contraire.
Un logiciel de reconnaissance vocale est un agent utilisateur dont les caractéristiques d'entrée et de sortie sont les suivantes :
En entrée : Une ou plusieurs grammaires comme les définit cette spécification. Ces grammaires informent le logiciel de reconnaissance des mots et combinaisons de mots à écouter ;
En entrée : Un flux sonore susceptible d'avoir un contenu vocal correspondant à la grammaire (ou aux grammaires) ;
En sortie : Des descriptions de résultats donnant des informations à propos du contenu vocal détecté par le logiciel de reconnaissance vocale. Le format et le détail du contenu du résultat ne sont pas décrits par cette spécification. Pour des besoins d'information, la plupart des logiciels de reconnaissance inclueront au moins une description des mots détectés.
En sortie : Des informations concernant les échecs ou d'autres opérations pouvant être fournies à l'environnement hôte, par exemple, à un navigateur vocal intégrant un processeur grammatical. La méthode d'interaction avec l'environnement hôte n'est pas décrite par cette spécification. Par contre, elle impose au processeur grammatical conforme d'informer l'environnement des erreurs rencontrées au cours de l'analyse et des autres traitements des documents de grammaire.
La vocation principale d'une grammaire de logiciel de reconnaissance vocale est de permettre à une application vocale d'indiquer au logiciel de reconnaissance vocale ce qu'il devrait écouter, précisément :
Les mots pouvant être synthétisés ;
Les combinaisons où ces mots peuvent apparaître ;
La langue de locution de chaque mot.
Les logiciels de reconnaissance vocale peuvent aussi utiliser la spécification des modèles de langues stochastiques (N-Gram) [NGRAM]. Les deux spécifications définissent des moyens pour installer un logiciel de reconnaissance vocale afin qu'il détecte une entrée prononcée, mais elles définissent les mots et combinaisons de mots selon des méthodes différentes et complémentaires. Certains logiciels de reconnaissance autorisent des références croisées entre les grammaires des deux formes. L'élément d'appel de règle de cette spécification décrit comment appeler un document N-Gram.
La spécification des grammaires ne traite pas nombre d'autres problèmes affectant les performances de la reconnaissance vocale. La plupart des capacités suivantes sont traitées selon le contexte d'appel ou d'invocation de la grammaire : par exemple, au travers du standard VoiceXML 2.0 [VXML2] ou au travers de l'interface de programmation (API) d'un logiciel de reconnaissance vocale.
Les données d'adaptation du locuteur : Certains logiciels de reconnaissance vocale peuvent s'ajuster dynamiquement à la voix du locuteur et souvent stocker les données d'adaptation de cette voix pour une utilisation ultérieur. Les données du locuteur peuvent également comprendre des listes de mots les plus employés par l'utilisateur. Le format des grammaires ne traite pas explicitement ces possibilités.
La configuration du logiciel de reconnaissance vocale : Le format des grammaires n'incorpore aucune méthode pour règler les paramètres des logiciels de reconnaissance tels que les délais d'attente, les seuils de reconnaissance, les étendues de recherche ou les comptes des n meilleurs résultats.
Le lexique : Le format des grammaires ne traite pas du chargement des lexiques ou de la prononciation des mots appelés par la grammaire. Le groupe de travail Voice Browser du W3C examine l'opportunité de développer un format lexical standard. Si cela devait avoir lieu, la présente spécification des grammaires ferait l'objet d'une mise à jour.
Les autres capacités de traitement vocal : Entre autres capacités, il existe des technologies de traitement vocal pour identifier la langue, pour authentifier le locuteur (appelée aussi empreinte vocale), pour reconnaître le locuteur (appelée aussi identification du locuteur). Quoique ces technologies puissent être associées au logiciel de reconnaissance vocale, elles ne sont pas traitées par cette spécification.
Les formes ABNF et XML sont définies pour assurer une correspondance sémantique entre les deux représentations. Il devrait être possible de convertir automatiquement une grammaire de forme ABNF en une grammaire de forme XML (ou inversement), de sorte que les fonctions sémantiques des grammaires soient identiques. L'équivalence des caractéristiques sémantiques implique que :
Les deux grammaire acceptent la même langue en entrée ou la rejettent en entrée
Les deux grammaires analysent de manière identique une chaîne quelconque en entrée.
Le document de transformation XSL dans l'annexe F démontre une conversion automatique depuis la forme XML vers la forme ABNF. La conversion réciproque nécessite un analyseur ABNF et un programme de transformation.
Il existe des limites inhérentes à la conversion automatique depuis la forme ABNF vers la forme XML, et inversement :
Les caractères blancs de formatage ne peuvent pas être conservés, et donc il n'y a aucune garantie qu'une grammaire de belle impression dans une forme soit convertie automatiquement en une grammaire de belle impression dans l'autre forme. Remarque : Les caractères blancs avec une signification syntaxique sont conservés.
Certaines structures XML n'ont pas d'équivalent dans ABNF : le schéma XML, la définition DTD, les déclarations et appels de caractères et d'entités, les instructions de traitement, les espaces de nommage. L'analyseur XML d'un processeur grammatical conforme devrait résoudre tous les appels de caractères et d'entités comme le définit XML 1.0 [XML] avant conversion vers la forme ABNF ; les autres structures sont perdues. Le langage RDF [RDF-SYNTAX] permet de représenter des métadonnées comme du XML dans les grammaires de forme XML mais on ne pouvait pas en fait l'utiliser dans les grammaires de forme ABNF, et il n'est donc pas utilisé.
L'ordonnancement des commentaires par rapport aux structures des grammaires peut être modifié.
Un logiciel de reconnaissance vocale est capable de comparer une entrée sonore à une grammaire afin de produire une transcription en texte brut (appelé aussi texte littéral) de l'entrée détectée. Le logiciel de reconnaissance peut effectuer un post-traitement du texte brut, sans y être obligé, pour produire une interprétation sémantique de l'entrée.
Par exemple, l'énoncé naturel Je veux faire une réservation sur un vol de Prague à Paris pourrait donner la structure de données XML suivante. Cette interprétation supplémentaire demande des instructions de traitement sémantique qui peuvent se trouver dans la grammaire définissant la sortie vocale légale, ou bien dans un document associé.
<réservation-vol>
<départ>Prague</départ>
<arrivée>Paris</arrivée>
</réservation-vol>
La spécification des grammaires de reconnaissance vocale fournit des méthodes syntaxiques limitées pour l'interprétation sémantique. La structure tag et les déclarations tag-format et tag offrent un paramètre substituable pour représenter les instructions destinées à un processeur sémantique.
Le groupe de travail Voice Browser du W3C développe actuellement la spécification L'interprétation sémantique de la reconnaissance vocale [SEM]. Cette spécification définit un langage qui peut être incorporé aux balises des grammaires de type SRGS pour accomplir le processus d'interprétation. Le traitement sémantique est défini par rapport à la structure d'analyse logique du traitement des grammaires (cf. l'annexe H). D'autres formats de balisage pourraient être utilisés mais ils n'entrent pas dans le cadre des activités du W3C.
Pour des exemples d'interprétation sémantique dans le dernier document de travail, cf. [SEM].
On peut représenter la sortie du processeur d'interprétation sémantique en utilisant le langage de balisage sémantique des langues naturelles (NLSML [NLSML]. Cette représentation XML de l'entrée vocale interprétée peut être utilisée comme entrée d'un traitement VoiceXML 2.0 [VXML2], ou d'autres façons.
L'interprétation sémantique effectuée au cours du processus de reconnaissance vocale se caractérise habituellement par :
Un contexte restreint : L'interprétation ne résoud pas les références déictiques ou anaphoriques, ou les autres formes linguistiques recouvrant plusieurs énoncés. Par exemple, si l'énoncé Je veux faire une réservation sur un vol de Prague à Paris était suivi par De là, je veux continuer sur Londres , la référence De là pourrait être résolue en Paris . Cela impose une analyse recouvrant plusieurs énoncés, qui est habituellement hors des compétences d'un logiciel de reconnaissance, mais pas de celles d'un gestionnaire de dialogues (par exemple, une application VoiceXML).
La spécifité du domaine : Une grammaire de reconnaissance vocale se limite généralement en entrée à un domaine restreint (par exemple, la collecte de données pour la réservation aérienne). Au sein de ce domaine, l'interprétation sémantique est une tâche envisageable, tandis que l'interprétation d'une langue entière reste un défi extraordinairement complexe.
La spécifité de la langue : Chaque langue ayant des structures linguistiques uniques, le processus de conversion d'un texte brut en un résultat sémantique dépend forcément de la langue.
Cette approche vise la forme restreinte d'interprétation sémantique. Une application VoiceXML recevant un résultat vocal avec une interprétation sémantique traitera habituellement l'entrée d'utilisateur pour entreprendre un dialogue. L'application peut aussi effectuer une analyse approfondie, par exemple, résoudre des références déictiques ou anaphoriques.
La spécification des grammaires de reconnaissance vocale est conçue pour permettre l'incorporation de grammaires de formes ABNF et XML dans d'autres documents. Par exemple, les langages VoiceXML 1.0 [VXML1] et VoiceXML 2.0 [VXML2] admettent les grammaires incorporées [VXML2 §3.1.1.1], c'est-à-dire une grammaire de forme ABNF ou XML directement contenue dans le document VoiceXML.
On peut incorporer une grammaire de forme XML dans un document XML en utilisant des espaces de nommage XML [XMLNS], ou en plaçant la définition du schéma XML (ou la définition DTD) de la grammaire dans le document englobant.
On peut incorporer une grammaire de forme ABNF dans n'importe quel document XML en tant que données textuelles. Les grammaires ABNF contiendront souvent des caractères chevrons < et > , qui réclament un traitement particulier dans XML. Il faudra peut-être utiliser une section de type CDATA [XML §2.7] ou les séquences de masquage &lt; et &gt; pour créer du code XML bien formé. Remarque : La forme ABNF utilise des caractères chevrons pour délimiter les adresses URI, les types de média ou les opérateurs de répétition.
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 dans ce document doivent s'interpréter selon le document [RFC2119]. Toutefois, pour des questions de lisibilité, ces mots n'apparaissent pas en lettres majuscules dans cette spécification.
Une adresse URI est une syntaxe unifiée pour exprimer les noms et adresses des objets sur le réseau comme utilisés sur le Web. Elle est définie comme une primitive de type anyURI légale définie par la recommandation XML Schema tome 2 : Les types de données [SCHEMA2 §3.2.17]. La définition XML Schema obéit aux documents [RFC2396] et [RFC2732]. La représentation syntaxique d'une adresse URI diffère entre les formes ABNF et XML. Tout appel d'adresse URI relative doit être résolu selon les règles données dans la section 4.9.1.
Adresse URI ABNF : Dans la forme ABNF de cette spécification, une adresse URI est délimitée par des caractères chevrons < et > . Par exemple, l'adresse <http://www.example.com/chemin-du-fichier>
Adresse URI XML : Dans la forme XML de cette spécification, toutes les adresses URI sont données comme attribut d'un élément. Par exemple, les éléments ruleref et lexicon.
Un type de média (défini dans les documents [RFC2045] et [RFC2046]) indique la nature d'une ressource reliée. Les types de média sont insensibles à la casse. On peut télécharger une liste des types de médias enregistrés [TYPES]. On peut fournir un type de média pour indiquer le type de contenu d'une adresse URI partout où elle peut apparaître.
[Cf. l'annexe G pour des renseignements sur les types de médias pour la forme ABNF et la forme XML de la spécification des grammaires de reconnaissance vocale.]
Adresse URI ABNF avec type de média : Dans la forme ABNF, on peut associer un type de média en suffixe à n'importe quelle adresse URI. Le type de média est délimité par des chevrons < et > , l'adresse URI et le type de média sont séparés par un caractère tilde ~ sans caractère blanc intermédiaire. Par exemple, <http://example.com/chemin-du-fichier>~<type-media>
Adresse URI XML avec type de média : Dans la forme XML, tout élément portant un attribut dont la valeur est une adresse URI peut recevoir un attribut type.
Un identificateur de langue marque l'appartenance d'un contenu d'information à une langue humaine particulière. Suivant la spécification XML pour l'identification des langues [XML §2.12], un identificateur de langue légal pour les grammaires de forme ABNF et XML est défini par un code RFC 3066 [RFC3066]. Le document RFC 3066 impose un code de langue. L'identificateur de code de pays (ou d'une autre sous-étiquette) est optionnel d'après le document RFC 3066. Une déclaration de langue de grammaire définit sa langue. En outre, une extension de règle légale peut être étiquetée par son contenu linguistique.
Un caractère blanc est constitué par un ou plusieurs caractères espaces ( #x20 ), retours chariots, sauts de ligne ou tabulations. La définition normative d'un caractère blanc pour les deux formes ABNF et XML reprend celle du langage XML [XML §2.3]. Les processeurs ABNF doivent également respecter la gestion des fins de lignes XML 1.0 [XML §2.11].
La norme DTMF (N.d.T. Dual Tone Multiple Frequency) est un standard ITU de signalisation téléphonique. La recommandation ITU Q.23 définit la génération DTMF et la recommandation Q.24 [Q24] la réception DTMF. Un processeur grammatical acceptant une entrée DTMF devrait mettre en œuvre la recommandation Q.24.
Une extension de règle légale est tout atome, tout appel de règle, toute balise légaux, ou toute combinaison logique d'extensions de règles légales telle qu'une séquence, des choix, une extension répétée ou une extension avec attribution de langue.
Une extension de règle est formellement une expression rationnelle (cf. par exemple, [HU79]).
Une définition de règle associe une extension de règle légale à un nom de règle.
Un atome (appelé aussi symbole terminal ) est la partie de la grammaire définissant les mots et autres entités prononçables. Tout atome légal est une extension légale.
Pour la reconnaissance vocale, un atome est habituellement une entité orthographique de la langue en cours d'analyse. Toutefois, un atome peut être n'importe quelle chaîne susceptible d'être convertie en une représentation phonétique par le logiciel de reconnaissance vocale.
Le contenu atomique : Pour la forme XML comme la forme ABNF, tout texte non balisé dans une définition de règle, sauf les exemples de phrases (seulement dans la forme XML) ou le contenu de balise, est un contenu atomique. Le texte non balisé est délimité par toute structure syntaxique de la forme de grammaire (cf. les informations ci-dessous sur la forme ABNF et la forme XML). Pour chaque étendue de contenu atomique dans la grammaire, le processeur grammatical effectue une atomisation, une normalisation des caractères blancs, une normalisation des atomes et un recherche de prononciation. Dans les deux formes XML et ABNF, tout le contenu atomique est traité comme des caractères dans [XML]. (Pour information : Le langage XML définit les caractères par rapport aux normes ISO/IEC 10646 [ISO/IEC 10646] et Unicode [Unicode].)
Le comportement d'atomisation : Les étendues de texte contenant des séquences atomiques sont délimitées comme suit :
Dans la forme XML uniquement : Un élément token peut seulement contenir des données textuelles. Les données textuelles sont traitées comme un seul atome non normalisé. Les données textuelles ne doivent pas contenir de caractère guillemet double " ;
Dans la forme ABNF ou dans la forme XML, tout atome (sauf dans un élément token pour la forme XML) peut être délimité par des guillemets doubles. Le texte contenu entre les guillemets doubles est un atome non normalisé. Le texte ne doit pas contenir de caractère guillemet double. Un atome délimité par des guillemets doubles peut contenir des caractères blancs ;
Tout contenu atomique non délimité par un élément token ou par des guillemets doubles est traité comme une séquence d'atomes délimités par des caractères blancs. Chaque atome dans le contenu atomique est délimité, au début et à la fin, par un caractère blanc ou par une structure syntaxique de délimitation d'étendue de contenu atomique. Les structures syntaxiques délimitant les contenus atomiques diffèrent pour la forme ABNF et la forme XML. Ces atomes ne peuvent pas contenir de caractères blancs.
Type atomique Forme Exemple
Atome seul sans guillemet ABNF & XML bonjour
Atome seul sans guillemet : non alphabétique ABNF & XML 2
Atome seul entre guillemets : avec caractère blanc ABNF & XML "San Francisco"
Atome seul entre guillemets : sans caractère blanc ABNF & XML "bonjour"
Deux atomes délimités par un caractère blanc ABNF & XML bon voyage
Quatre atomes délimités par des caractères blancs ABNF & XML ceci est un essai
Atome XML seul dans un élément token XML uniquement <token>San Francisco</token>
La normalisation des caractères blancs : Les caractères blancs doivent être normalisés lorsqu'ils sont contenus dans un atome délimité par un élément token, ou par des guillemets doubles. Les caractères blancs de tête et de queue sont supprimés. Tout caractère blanc ou toute séquence de caractères blancs dans un atome interne sont ramenés à un seul caractère espace ( #x20 ). Ainsi, les exemples suivants donnent tous la même chaîne San Francisco .
Puisque la présence de caractères blancs dans un atome est significative, les atomes suivants sont distincts :
La normalisation des atomes : D'autres processus de normalisation sont effectués sur les atomes avec des caractères blancs normalisés, conformément à la langue et aux capacités du logiciel de reconnaissance vocale.
Les processeurs grammaticaux peuvent supposer une normalisation uniforme précoce (N.d.T. early uniform normalization), comme défini dans Un modèle de caractères pour le Web 1.0 [CHARMOD §4].
La recherche de prononciation : Pour comparer l'entrée prononcée (sonore) à une grammaire, le logiciel de reconnaissance vocale doit être capable de modéliser les motifs sonores de tout atome dans la grammaire. Les logiciels de reconnaissance vocale utilisent plusieurs techniques pour réaliser ce processus-clé de la reconnaissance vocale. Voici une description informative des techniques applicables par un logiciel de reconnaissance vocale s'appuyant sur une technologie de reconnaissance vocale à vocabulaire étendu conventionnelle.
Le logiciel de reconnaissance vocale à vocabulaire étendu convertit chaque atome normalisé en une séquence de phonèmes ou un ensemble de séquences de phonèmes possibles. La conversion d'une forme orthographique (atome) vers la forme prononcée (phonèmes) est un processus fortement dépendant de la langue. Dans beaucoup de cas, la conversion est même propre à une variante nationale, à un dialecte régional ou à une autre variante de la langue. Par exemple, certains atomes du français parlé à Paris, au Québec et en Suisse seront convertis chacun avec une prononciation différente.
La conversion texte à phonèmes dans un logiciel de reconnaissance vocale à vocabulaire étendu peut faire intervenir tous ou une partie des sous-processus suivants :
La consultation d'un lexique de prononciation : L'un des éventuellement nombreux lexiques mis à la disposition d'un logiciel de reconnaissance peut fournir la séquence de phonèmes d'un atome. Les deux formes ABNF et XML permettent aux grammaires de définir un ou plusieurs documents de lexique. Les logiciels de reconnaissance proposent habituellement un lexique intégré pour chaque langue prise en charge, quoique la couverture puisse varier d'un programme à l'autre. L'algorithme par lequel la comparaison résoud un atome en une prononciation est défini par le format du lexique et/ou le logiciel de reconnaissance vocale, et il peut être propre à la langue. On recommande des comparaisons de chaînes insensibles à la casse.
L'analyse morphologique : Un logiciel de reconnaissance vocale peut déterminer la transformation depuis un atome élémentaire et une chaîne de phonème vers une variante morphologique et sa prononciation. Par exemple, connaissant la prononciation du terme cheval , une règle pourrait inférer la prononciation de la forme plurielle chevaux .
La conversion texte à phonèmes automatique : Pour beaucoup de langues et d'écritures (mais pas toutes), il existe des règles pour convertir automatiquement un atome en une séquence de phonèmes. Par exemple, en anglais, la plupart des mots terminés par la séquence de lettres ise (mais pas tous) se traduisent par la séquence de phonème aï z . Un logiciel de reconnaissance vocale peut utiliser d'une conversion automatique pour inférer la prononciation d'atomes absents d'un lexique.
Toute langue utilisera probablement d'autres processus spécialisés pour déterminer la prononciation d'un atome. Par exemple, le japonais nécessite des techniques particulières pour le Kanji et chaque forme Kana.
Quels que soient la langue et le logiciel de reconnaissance, il peut exister des variations dans la couverture et l'exhaustivité des atomes de la langue.
Si un processeur grammatical manipule une grammaire contenant un atome qu'il ne peut pas convertir en une forme phonémique, ou sinon utiliser dans le traitement de reconnaissance sonore, alors il devrait en informer l'environnement hôte.
Les limitations de la manipulation des atomes : Voici un guide informatif pour les développeurs de grammaires.
L'activité Pronunciation Lexicon [LEX] du groupe de travail Voice Browser du W3C fournira des indications sur les processus de manipulation d'atomes esquissés précédemment.
La manipulation des atomes sera variable entre les logiciels de reconnaissance et entre les langues.
Les auteurs de grammaires peuvent améliorer la portabilité des documents en évitant d'utiliser pour les atomes des caractères et des formes dont la prononciation n'est pas évidente dans la langue. En ce qui concerne le français, voici comment utiliser certaines formes orthographiques :
Il faudrait éviter les sigles. Les caractères alphabétiques devraient être les plus nombreux. Par exemple, remplacez USA par u s a , W3C par w trois c , IEEE par i triple e ;
Il faudrait remplacer les abréviations par leur forme non abrégée. Par exemple, remplacez av. par avenue , ou M. par monsieur ;
Il faudrait développer la ponctuation vers une forme orthographiée. Par exemple, remplacez & par esperluette ou et , + par plus , < par inférieur à ou chevron ouvrant .
Un processeur grammatical devrait prendre en compte les chiffres (par exemple, "0" à "9" pour les écritures européennes). On devrait remplacer les autres nombres naturels par leur forme orthographiée. Par exemple, pour le français, remplacez "10" par dix , et "1000" par mille .
Les auteurs de grammaires devraient envisager qu'une grammaire puisse servir pour interpréter l'entrée d'un appareil non vocal. Par exemple, elles peuvent servir pour traiter les chaînes textuelles provenant d'une saisie au clavier, de services téléphoniques textuels, d'un stylo optique ou d'autres dispositifs textuels. Une grammaire devrait contenir les atomes orthographiques de référence de la langue pour faciliter la saisie du texte. À savoir, pour faciliter une entrée non vocale, elle devrait contenir le plus possible de mots de la langue naturelle dans leur orthographe de référence.
La forme ABNF
Tout texte ordinaire dans une définition de règle est un contenu atomique. La syntaxe ABNF (cf. annexe D) définit normativement le déroulement de l'analyse des atomes.
On peut associer une langue à n'importe quel atome. Auquel cas, elle modifie uniquement le traitement de l'atome.
L'extension de règle d'une définition de règle est délimitée par un signe égal = au début et par un caractère point-virgule ; à la fin. Tout texte ordinaire en tête de l'extension de règle est délimité par un signe égal, et de même tout texte ordinaire se termine par un point-virgule.
Dans une extension de règle, les symboles suivants possèdent une fonction syntaxique et délimitent du texte ordinaire.
Un signe dollar $ et des crochets en chevron < et > si besoin marquent les appels de règles ;
Des parenthèses ( et ) peuvent englober une extension de règle ;
Une barre verticale | délimite des options ;
Des barres obliques / délimitent des poids d'options ;
Des crochets en chevron < et > délimitent un opérateur de répétition ;
Des crochets [ et ] délimitent une extension optionnelle
Des accolades { et } délimitent une balise
Un point d'exclamation ! préfixe un identificateur de langue
Au sein des zones de texte ordinaire délimitées par ces caractères, les processus d'atomisation, de normalisation des caractères blancs, de normalisation des atomes et de recherche de prononciation décrits précédemment s'appliquent.
La forme XML
Tout élément token délimite explicitement un seul atome comme décrit précédemment. L'élément token peut inclure un attribut optionnel xml:lang indiquant la langue de l'atome contenu.
Toutes autres données textuelles dans un élément rule (définition de règle) ou dans un élément item constituent un contenu atomique. Remarquez que les données textuelles dans les éléments tag ou example ne constituent pas un contenu atomique.
Tout appel de règle légal est une extension de règle légale.
Les noms de règles : Chaque définition de règle comporte un nom local qui doit être unique dans le cadre de la grammaire où il est défini. Un nom de règle doit correspondre à la production Nom de la spécification XML 1.0 [XML §2.3] et être un identificateur XML légal. La section 3.1 expose le mécanisme de définition des règles et leur nommage légal.
Ce tableau résume les diverses formes d'appel de règle possibles, au sein d'un document de grammaire ou bien depuis un document de grammaire à un autre.
Remarque : Un document de grammaire de forme XML doit comporter un seul des attributs uri ou special sur un élément ruleref. Il n'y a aucune contrainte équivalente pour la forme ABNF, car les formes syntaxiques sont distinctes.
Type d'appel Forme ABNF Forme XML
2.2.1 : Appel explicite d'une règle locale $rulename <ruleref uri="#rulename"/>
2.2.2 : Appel explicite d'une règle nommée dans une grammaire identifiée par une adresse URI $<grammarURI#rulename> <ruleref uri="grammarURI#nom-regle"/>
2.2.2 : Appel implicite de la règle racine d'une grammaire identifiée par une adresse URI $<grammarURI> <ruleref uri="grammarURI"/>
2.2.2 : Appel explicite d'une règle nommée dans une grammaire identifié par une adresse URI avec un type de média $<grammarURI#rulename>~<media-type> <ruleref uri="grammarURI#rulename" type="media-type"/>
2.2.2 : Appel implicite de la règle racine d'une grammaire identifiée par une adresse URI avec un type de média $<grammarURI>~<media-type> <ruleref uri="grammarURI" type="media-type"/>
2.2.3 : Définitions de règle spéciales $NULL
Pour appeler des règles définies localement (c'est-à-dire dans la même grammaire contenant l'appel), utilisez toujours un appel de nom de règle simple composé du nom de règle locale seul. La forme ABNF et la forme XML ont une syntaxe différente pour représenter un appel de nom de règle simple.
L'appel de nom de règle simple est préfixé par un caractère dollar $ .
$chiffre
L'élément ruleref est un élément vide avec un attribut uri définissant l'appel de règle comme une adresse URI d'appel dans le même document [RFC2396]. À savoir, la valeur d'attribut se compose seulement d'un caractère dièse # et de l'identificateur de fragment indiquant le nom de règle appelé localement.
<ruleref uri="#ville"/>
<ruleref uri="#chiffre"/>
Les appels de règles définies dans d'autres grammaires sont légaux aux conditions définies dans la section 3. L'appel externe doit identifier la grammaire externe par une adresse URI, et il peut identifier une règle particulière au sein de cette grammaire. Si l'identificateur de fragment censé désigner un nom de règle était omis, alors l'appel viserait implicitement la règle racine root de la grammaire externe.
Toute règle appelée de l'extérieur peut être activée pour la reconnaissance. À savoir, elle peut définir la syntaxe de premier niveau d'une entrée prononcée. Par exemple, l'activation d'une grammaire VoiceXML [VXML2] peut appeler explicitement une ou plusieurs règles publiques (cf. la section 3.2) et/ou appeler implicitement la règle racine (cf. la section 4.7).
L'appel d'adresse URI est illégal si le document appelant et le document appelé obéissent à des modes différents. Par exemple, l'appel d'une grammaire "dtmf" depuis une grammaire "voice" est interdit. (Cf. la section 4.6 pour des précisions à propos des modes).
La ressource désignée par un appel d'adresse URI peut éventuellement être disponible dans un ou plusieurs types de média. L'auteur de la grammaire peut indiquer un type de média préféré au moyen de l'attribut type (forme XML), ou entre des crochets en chevron à la suite de l'adresse URI (forme ABNF). Lorsque le contenu représenté par une adresse URI est disponible dans plusieurs formats de données, le processeur grammatical peut utiliser le type de média préféré pour déterminer lequel des formats choisir. Par exemple, dans le cas d'un serveur capable d'une négociation de contenu HTTP, le processeur peut utiliser le type de média préféré pour ordonner les préférences de la négociation.
La représentation de la ressource obtenue à la suite 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 affirmé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, à cause d'un serveur HTTP mal configuré annonçant comme type du document de grammaire, une valeur text/plain au lieu de application/srgs+xml ). Un système d'adressage URI spécifique peut imposer au possesseur de la ressource de toujours renvoyer le type du média, ou bien parfois, ou bien jamais. Le type de média déclaré est la valeur renvoyée par le possesseur de la ressource, ou c'est le type de média préféré donné dans la grammaire si aucune valeur n'est renvoyée. Il peut n'y avoir aucun type de média déclaré si le possesseur de la ressource ne renvoie aucune valeur, ou si aucun type de média préféré n'est indiqué. Le type de média déclaré fait autorité s'il est défini.
Trois cas particuliers peuvent se produire. Le type de média déclaré n'est peut-être pas géré par le processeur : c'est une condition d'erreur. Le type de média déclaré est géré mais le type de média réel ne correspond pas : c'est aussi une condition erreur. Enfin, aucun type de média n'est déclaré : le comportement dépend alors du système d'adressage URI particulier et des capacités du processeur grammatical. Par exemple, le protocole HTTP 1.1 autorise l'introspection du document (cf. le document RFC 2616, chapitre 7.2.1), le schéma de données se replie sur un type de média par défaut, ou l'accès au fichier local ne définit aucune directive. Le tableau suivant donne 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 Erreur : 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 la grammaire reconnaît le type application/srgs+xml , erreur sinon Particularité du système : le processeur grammatical peut examiner le document afin d'en déterminer le type.
Cf. l'annexe G pour un récapitulatif de l'état des types de média des grammaires de forme ABNF et de forme XML.
Dans la forme ABNF, un appel externe par adresse URI est représenté par un signe dollar $ suivi immédiatement par une adresse URI ABNF, ou bien par une adresse URI ABNF avec un type de média. Il ne doit y avoir aucun caractère blanc entre le signe dollar et l'adresse URI.
// Appels de règles particulières d'une grammaire externe
// Appel implicite de la règle racine d'une grammaire externe
// Appels avec type de média associé
Remarque : L'enregistrement du type de média application/srgs a été demandé pour les grammaires de forme ABNF. Cf. l'annexe G pour des précisions.
L'appel de règle XML se présente sous la forme d'un élément ruleref avec un attribut uri définissant l'adresse URI de la grammaire appelée et de la règle qui s'y trouve. Si un identificateur de fragment est ajouté, il désigne un nom de règle particulier. Si l'identificateur de fragment est omis, c'est un appel (implicite) de la règle racine de la grammaire appelée.
L'attribut optionnel type indique le type de média de la grammaire contenant l'appel.
<!-- Appels de règles particulières d'une grammaire externe -->
<ruleref uri="http://grammar.example.com/numbers.grxml#chiffre"/>
<!-- Appel implicite de la règle racine d'une grammaire externe -->
<!-- Appels avec un type de média associé -->
Remarque : L'enregistrement du type de média application/srgs+xml a été demandé pour les grammaires de forme XML. Cf. l'annexe G pour des précisions sur les types de médias des grammaires.
Certains noms de règles font l'objet d'une interprétation et d'un traitement particuliers par les logiciels de reconnaissance vocale. Aucune grammaire ne doit redéfinir ces noms de règles.
Dans la forme ABNF, la syntaxe d'un appel de règle spéciale est identique à celle d'un appel de règle locale. Par contre, les noms des règles spéciales sont réservés pour prévenir les définitions de règles de même nom.
Dans la forme XML, un nom de règle spéciale est représenté par un attribut special sur un élément ruleref. La présence simultanée d'un attribut special et d'un attribut uri est illégale.
Définit une règle automatiquement vérifiée. À savoir, elle est vérifiée sans que le locuteur ne prononce un mot.
Forme ABNF : $NULL
Forme XML : <ruleref special="NULL"/>
Définit une règle jamais prononçable. L'insertion d'une règle VOID dans une séquence la rend automatiquement imprononçable.
Forme ABNF : $VOID
Forme XML : <ruleref special="VOID"/>
Définit une règle correspondant à toute parole jusqu'à la prochaine règle vérifiée, au prochain atome ou au terme de l'entrée prononcée. Un processeur grammatical doit accepter les grammaires contenant des appels spéciaux de la règle GARBAGE. Le comportement de la règle GARBAGE dépend de la mise en œuvre. Un agent utilisateur devrait être capable de filtrer une entrée prononcée arbitraire jusqu'au prochain atome, mais il peut aussi considérer la règle GARBAGE comme équivalente de la règle NULL (aucune entrée prononcée n'est filtrée).
Forme ABNF : $GARBAGE
Forme XML : <ruleref special="GARBAGE"/>
Exemple informatif : Avec des définitions convenables des villes et états des États-Unis, un logiciel de reconnaissance vocal peut mettre en œuvre les définitions de règle ABNF et XML suivantes pour filtrer Philadelphie dans le grand état de Pennsylvanie ainsi que simplement Philadelphie Pennsylvanie .
2.2.4 L'appel des documents de grammaire N-Gram (informatif)
Le groupe de travail Voice Browser du W3C a publié une version préliminaire de la Spécification des modèles de langue stochastiques (N-Gram) [NGRAM]. Ces deux spécifications représentent des façons différentes et complémentaires d'informer un logiciel de reconnaissance vocale des mots et combinaisons de mots à écouter.
Un logiciel de reconnaissance vocal peut choisir de mettre en œuvre la spécification des grammaires de reconnaissance vocale N-Gram en plus de la grammaire de reconnaissance vocale définie dans le présent document.
Si le logiciel de reconnaissance vocale met en œuvre les deux représentations grammaticales, il peut en option gérer les appels entre ces deux formats. Les grammaires définies dans la forme ABNF ou dans la forme XML peuvent appeler les symboles de départ des documents N-Gram, et vice versa.
La syntaxe d'appel d'un document N-Gram est la même que celle des documents de grammaire de forme ABNF ou XML définis ailleurs. On recommande d'utiliser un type de média pour l'appel d'un document N-Gram. Le groupe de travail n'a pas encore fait de demande de type pour les documents N-Gram, et aucun exemple n'est donc fourni. L'identificateur de fragment (un nom de règle pour appeler les grammaires de forme ABNF et de forme XML) repère un symbole de départ comme le définit la spécification N-Gram. Si le symbole de départ est absent, le document N-Gram est appelé dans sa totalité, comme l'indique la spécification N-Gram.
Les appels d'adresses URI de documents N-Gram obéissent à la même syntaxe que les appels d'autres documents de grammaire de forme ABNF ou XML. Voici des exemples d'appels d'un document N-Gram avec un appel de règle explicite et un appel implicite de la règle racine.
Les appels d'adresses URI des document N-Gram obéissent à la même syntaxe que les appels d'autres documents de grammaire de forme ABNF ou XML. Voici des exemples d'appels d'un document N-Gram avec un appel de règle explicite et un appel implicite de la règle racine.
Une séquence d'extensions de règles légales est elle-même une extension de règle légale.
La séquence des extensions de règles détermine la succession temporelle selon laquelle l'agent utilisateur devra détecter les extensions. Cette contrainte s'applique aux séquences d'atomes, aux séquences d'appels de règles, aux séquences de balises, aux expressions entre parenthèses et toutes combinaisons de ces extensions de règles.
La forme ABNF et la forme XML disposent toutes deux d'une syntaxe permettant d'encapsuler une extension quelconque. Par exemple, elle sert à associer un opérateur de répétition, un identificateur de langue ou à assurer un ordre de priorité exact pour l'analyse (dans la forme ABNF uniquement).
Une séquence d'extensions légales, séparées par des caractères blancs, est une extension légale.
Une extension légale entre parenthèses ( et ) est une extension légale.
voici un essai           // séquence d'atomes
$action $objet           // séquence d'appels de règles
cet $objet est $couleur  // séquence d'atomes et d'appels de règles
(vol pour $ville)        // parenthèses d'encapsulation
Une expression entre parenthèses vide est légale tout comme une expression entre parenthèses contenant seulement des caractères blancs, par exemple, () ou ( ) . Les deux formes équivalent à une règle $NULL, et le processeur grammatical agira comme si les expressions entre parenthèses n'existaient pas.
// séquences équivalentes
telephone ( ) maison
Une séquence d'éléments d'extension de règle XML (ruleref, item, one-of, token, tag) et de sections CDATA contenant des atomes séparés par des espaces doit être reconnue lorsqu'elle apparaît dans une séquence temporelle. (La seule exception est lorsqu'un ou plusieurs éléments item apparaissent au sein d'un élément one-of.)
Un élément item peut contenir une expression quelconque et permet d'associer un attribut repeat ou un identificateur de langue. L'attribut weight d'un élément item est ignoré, sauf si l'élément apparaît au sein d'un élément one-of.
<!-- séquence d'atomes -->
<!-- séquence d'appels de règles -->
<ruleref uri="#action"/> <ruleref uri="#objet"/>
<!-- séquence d'atomes et d'appels de règles -->
cet <ruleref uri="#objet"/> est <ruleref uri="#couleur"/>
<!-- conteneur de séquence -->
<item>vol pour <ruleref uri="#ville"/> </item>
Un élément item vide est légal tout comme un élément item contenant seulement des caractères blancs. Les deux formes équivalent à un appel de la règle NULL, et le processeur agira comme si l'élément item n'existait pas.
<!-- séquences équivalentes -->
telephone <item/> maison
telephone <item></item> maison
telephone <item>    </item> maison
Tout ensemble de choix d'extensions de règles légales est lui-même une extension de règle légale. Pour correspondre à un ensemble de choix d'extensions de règles, une entrée doit correspondre à l'un des choix d'extension de l'ensemble. Un ensemble de choix doit en contenir un ou plusieurs.
Tout ensemble de choix peut avoir une étiquette d'association de langue. Dans la forme XML, elle se manifeste par un attribut xml:lang sur un élément one-of. Dans la forme ABNF, pour assurer l'ordre de priorité exact, l'ensemble de choix doit être délimité par des parenthèses, suivies immédiatement par l'association de langue ABNF.
On peut en option donner un poids à un nombre quelconque de choix dans une extension de choix. Les poids sont des valeurs en virgule flottante simples positives simples sans exposant. Les formats admis sont les suivants : n, n., .n et n.n, où n représente une séquence d'un ou plusieurs chiffres.
Un poids représente nominalement un facteur de multiplication dans le domaine probable d'une recherche de reconnaissance vocale. Un poids de "1.0" revient à ne pas fournir de poids du tout. Un poids supérieur à "1.0" fait valoir le choix positivement, et inversement, un poids inférieur à "1.0" fait valoir le choix négativement.
Les documents [JEL98] et [RAB93] constituent des références informatives sur le sujet de la technologie de reconnaissance vocale et sur le cadre statistique sous-jacent dans lequel s'appliquent les poids.
Les auteurs de grammaires et les développeurs de logiciels de reconnaissance vocale devraient connaître les limitations suivantes de la définition et l'application des poids comme présentés précédemment :
L'application des poids sur une recherche de reconnaissance vocale a lieu sous le contrôle interne du logiciel de reconnaissance. Il n'y a pas d'algorithme normatif ni informatif d'application des poids. En outre, la reconnaissance vocale est un processus statistique, et la cohérence du comportement ne peut donc pas être garantie ;
Il est difficile de déterminer les poids appropriés pour une grammaire ou pour un logiciel de reconnaissance particuliers. Estimer les poids n'améliore pas toujours les performances de la reconnaissance vocale ;
Les poids les plus efficaces sont obtenus en étudiant une entrée vocale réelle dans la grammaire. Par exemple, une technique raisonnable pour développer des poids portables consiste à utiliser des poids corrélés au compte des apparitions d'un ensemble de choix ;
Ajuster des poids à un logiciel de reconnaissance particulier ne garantit pas de meilleures performances pour d'autres logiciels de reconnaissance vocale.
Un ensemble d'options est identifié par une liste d'extensions légales, séparées par un symbole barre verticale | . L'ensemble d'options peut être délimité par des parenthèses si besoin.
Michael | Yuriko | Mary | Duke | $autresNoms
Un poids se présente entre des caractères barre oblique / et il se place avant chaque article dans la liste d'options.
/10/ petit | /2/ moyen |  grand
/3.1415/ tarte | /1.414/ limonade | /.25/ soda
Un choix peut légalement être un appel de la règle $NULL, un ensemble vide entre parenthèses ou une balise seule. Dans chaque cas, l'entrée équivaut à filtrer $NULL, et les autres choix sont alors optionnels.
$regle1 = mot | $NULL;
$regle2 = () | mot;
$regle3 = mot | {CONTENU-DE-BALISE};
Un choix vide (composé uniquement de caractères blancs) n'est pas légal.
// ILLÉGAL
$regle1 = a | | b;
$regle2 = | b;
$regle3 = a |;
La structure suivante sera interprétée comme un choix avec un seul poids.
$regle1 = /2/ mot;
$regle2 = /2/ {CONTENU-DE-BALISE};
$regle3 = /2/ $NULL;
L'élément one-of identifie un ensemble d'éléments de choix. Chaque extension de choix est contenue dans un élément item. Il doit y avoir au moins un élément item contenu dans un élément one-of. Les poids sont indiqués en option par un attribut weight sur l'élément item.
<item><ruleref uri="#autresNoms"/></item>
<item weight="10">petit</item>
<item weight="2">moyen</item>
<item>grand</item>
<item weight="3.1415">tarte</item>
<item weight="1.414">limonade</item>
<item weight=".25">soda</item>
Un élément one-of contenant un seul élément item est légal à condition que l'entrée corresponde au seul article. L'article seul peut en option recevoir un poids :
<item>mot</item>
<item weight="2.0">mot</item>
Un choix peut légalement être un appel de la règle NULL, un élément item vide ou une balise seule. Dans chaque cas, l'entrée équivaut à filtrer NULL, et les autres choix sont alors optionnels.
<item> <tag>CONTENU-DE-BALISE</tag> </item>
Toute extension de règle légale répétée est elle-même une extension de règle légale.
On dispose d'opérateurs qui définissent une extension de règle légale pour être une autre sous-extension optionnelle, c'est-à-dire qui se répète zéro à plusieurs fois, ou une ou plusieurs fois, ou un certain nombre de fois.
Forme ABNF
Exemple Forme XML
Exemple Comportement
repeat="6" L'extension contenue se répète exactement n fois ; n doit être un entier positif ou nul.
repeat="4-6" L'extension contenue se répète entre m et n fois (inclus) ; m et n doivent tous deux être des entiers positifs ou nuls, et m doit être inférieur ou égal à n.
repeat="3-" L'extension contenue se répète m fois ou plus (inclus) ; m doit être un entier positif ou nul. Par exemple, la valeur "3-" indique que l'extension contenue peut se produire trois, quatre, cinq fois ou plus.
[...] repeat="0-1" L'extension contenue est optionnelle.
Les répétitions courantes
Comme indiqué dans le tableau précédent, une extension pouvant advenir 0-1 fois est optionnelle. Puisque les choix sont très courants, la syntaxe ABNF utilise des crochets comme opérateur spécial pour représenter les options.
Une valeur de répétition de 0- indique que l'extension peut advenir zéro fois, une seule fois ou un nombre de fois quelconque. Dans les langages d'expressions rationnelles, cela est souvent représenté par une étoile de Kleene * , un caractère réservé mais pas utilisé dans la forme ABNF.
Une valeur de répétition de 1- indique qu'une extension peut advenir une seule fois ou un nombre de fois quelconque. Dans les langages d'expressions rationnelles, cela est souvent représenté par une clotûre positive ( + ), un caractère réservé mais pas utilisé dans la forme ABNF.
Quoique les deux formes ABNF et XML gèrent des grammaires admettant un nombre illimité d'atomes en entrée, les utilisateurs ne parleront pas indéfiniment. La reconnaissance vocale fonctionnera peut-être mieux si l'auteur indique un nombre de répétitions limité.
Lorsqu'on exprime un certain nombre de répétitions possibles (par exemple, <m-> ou <m-n>, où n > 0, mais différent de <0>) sur une structure dont le contenu se compose seulement d'éléments tag, le comportement du processeur grammatical n'est pas défini, et il dépendra des mises en œuvre particulières.
Un nombre quelconque de répétitions non optionnelles (par exemple, <m-n> où m > 0) de la règle VOID équivaut à une seule règle VOID.
Le comportement d'un processeur grammatical pour manipuler un nombre quelconque de répétitions de la règle NULL n'est pas défini, et il dépendra des mises en œuvre particulières.
Si le nombre de répétitions d'une extension peut seulement être de zéro (c'est-à-dire, <0> ou <0-0>), alors l'extension équivaut à la règle NULL.
Tout opérateur de répétition peut définir une probabilité de répétition optionnelle. La valeur indique la probabilité de répétition successive de l'extension répétée.
Une valeur de probabilité de répétition doit se trouver dans l'intervalle en virgule flottante de "0.0" à "1.0" (inclus). Les valeurs situées hors de cet intervalle sont illégales. Le format en virgule flottante est l'un des suivants : n, n., n.nnnn, .nnnn (avec un nombre quelconque de chiffres après le point).
Remarque : Les probabilités de répétition et les poids sont des entités logiques différentes, et leur impact diffère sur une recherche de reconnaissance vocale.
Exemple informatif : Un exemple simple serait celui d'une extension optionnelle (zéro ou une seule occurrence) avec une probabilité de "0.6". La grammaire indique que la probabilité de correspondance avec l'extension sera de 60 % et que la probabilité d'absence de cette extension de 40 %.
Si aucune valeur maximale n'est indiquée sur un intervalle ( m- ), les probabilités décroissent de façon exponentielle.
Les auteurs de grammaires et les développeurs de logiciels de reconnaissance vocale devraient connaître les limitations suivantes de la définition et de l'application de probabilités de répétition comme souligné précédemment :
L'application de probabilités de répétition à une recherche de reconnaissance vocale est sous le contrôle interne du logiciel de reconnaissance. Aucun algorithme n'est défini en ce qui concerne l'application de probabilités de répétition dans un processeur de reconnaissance vocale, et la cohérence du comportement ne peut donc pas être garantie ;
Il est souvent difficile de déterminer des probabilités de répétition appropriées pour une grammaire ou un logiciel de reconnaissance. Estimer des probabilités de répétition n'améliore pas toujours les performances de la reconnaissance vocale ;
Les probabilités de répétition les plus appropriées sont obtenues en étudiant les modèles statistiques d'une entrée vocale réelle. Ajuster des probabilités de répétition à un logiciel de reconnaissance particulier ne garantit pas de meilleures performances de reconnaissance pour d'autres logiciels de reconnaissance vocale.
Comme références utiles concernant les modèles statistiques de reconnaissance vocale, on consultera les documents [JEL98] et [RAB93].
Voici des opérateurs postfixes : <m-n> <m-> <m> . Un opérateur postfixe est accolé logiquement à l'extension précédente. Les opérateurs postfixes ont une priorité élevée et ils sont donc étroitement liés à l'extension immédiatement précédente (cf. le chapitre 2.8).
On peut délimiter des extensions optionnelles avec des crochets : [extension] . Au contraire, l'opérateur postfixe <0-1> indique une extension optionnelle.
Les symboles suivants sont réservés pour une utilisation ABNF ultérieure : l'astérisque * , le signe plus + , le point d'interrogation ? . On ne doit pas utiliser ces symboles là où la syntaxe actuelle permet la présence d'un opérateur de répétition dans une grammaire.
// L'atome très  est optionnel
[très]
très <0-1>
// L'appel de la règle $chiffre peut advenir zéro, une ou plusieurs fois
$chiffre <0->
// L'appel de la règle $chiffre peut advenir une ou plusieurs fois
$chiffre <1->
// L'appel de la règle $chiffre peut advenir quatre, cinq ou six fois
$chiffre <4-6>
// L'appel de la règle $chiffre peut advenir dix fois ou plus
$chiffre <10->
// Exemples des extensions suivantes
//   "grande pizza au poivron"
//   "très grande pizza au fromage et au poivron"
[[très] grande] pizza ([au | et] $garniture) <0->
Les probabilités de répétition ne sont prises en compte que dans une forme à intervalle. Une probabilité est délimitée avec des caractères barre oblique / et contenue entre des crochets en chevron : <m-n /probabilité/> et <m- /probabilité/> .
// L'atome très  est optionnel,
// sa probabilité d'apparition est de 60 % dans l'entrée,
// et sa probabilité d'absence est donc de 40 %
très <0-1 /0.6/>
// L'appel de la règle $chiffre doit advenir de deux à quatre fois
// avec une probabilité de récurrence de 80 %.
$chiffre <2-4 /.8/>
L'élément item a un attribut repeat indiquant le nombre de fois où l'extension contenue peut se répéter. L'exemple suivant illustre les valeurs acceptées par l'attribut.
<!-- L'atome très  est optionnel -->
<item repeat="0-1">très</item>
<!-- L'appel de la règle chiffre  peut advenir zéro, une ou plusieurs fois -->
<item repeat="0-"> <ruleref uri="#chiffre"/> </item>
<!-- L'appel de la règle chiffre  peut advenir une ou plusieurs fois -->
<item repeat="1-"> <ruleref uri="#chiffre"/> </item>
<!-- L'appel de la règle chiffre  peut advenir quatre, cinq ou six fois -->
<item repeat="4-6"> <ruleref uri="#chiffre"/> </item>
<!-- L'appel de la règle chiffre  peut advenir dix fois ou plus -->
<item repeat="10-"> <ruleref uri="#chiffre"/> </item>
<!-- Exemples de l'extension suivante -->
<!--   "grande pizza au poivron" -->
<!--   "très grande pizza au fromage et au poivron" -->
<item repeat="0-1"> très </item>
<item>et</item>
<ruleref uri="#garniture"/>
L'attribut repeat-prob sur l'élément item donne la probabilité de répétition. Les probabilités de répétition sont acceptées sur tout élément item, mais elles sont ignorées si l'attribut repeat n'est pas défini aussi.
<-- L'atome très  est optionnel et il a une probabilité d'apparition de 60 %. -->
<-- Cela signifie que la probabilité d'absence de très  dans l'entrée est de 40 % -->
<item repeat="0-1" repeat-prob="0.6">très</item>
<-- L'appel de la règle chiffre  doit advenir de deux à quatre fois -->
<-- avec une probabilité de récurrence de 80 %. -->
Une balise est une extension de règle légale (on peut aussi déclarer une balise dans l'en-tête du document de grammaire, cf. le chapitre 4.1).
Une balise est une chaîne arbitraire qui peut être incluse directement dans toute extension de règle. On peut inclure un nombre quelconque de balises dans une extension de règle.
Les balises n'affectent pas les combinaisons de mots légales définies par les grammaires ni le processus de reconnaissance vocale ni une autre entrée avec une grammaire.
Les balises peuvent abriter un contenu susceptible d'interprétation sémantique. Les processus d'interprétation sémantique peuvent influer sur le résultat de la reconnaissance.
Les associations de langue n'ont aucun effet sur les balises.
La déclaration du format de balise indique le type de contenu de toutes les balises de la grammaire.
On peut employer légalement une balise comme extension autonome. Par exemple, une règle peut être développée en une seule balise sans atome.
$regle = {CONTENU-DE-BALISE};
<rule id="regle"><tag>CONTENU-DE-BALISE</tag></rule>
Une balise est délimitée soit par des accolades { et } , soit par les séquences de trois caractères suivantes dont l'apparition au sein d'une balise est très improbable, à savoir {!{ et }!} . Une balise délimitée par des accolades ne peut pas contenir de caractère accolade fermante seul ( } ), et de même une balise délimitée par les séquences de trois caractères ne peut pas contenir la séquence fermante ( }!} ).
Le contenu de la balise est constitué de tout le texte situé entre les séquences de caractères d'ouverture et de fermeture, y compris les caractères blancs de tête ou de queue. Le processeur grammatical n'analyse pas le contenu de la balise.
L'ordre de priorité des balises est le même que celui des appels de règles et celui des atomes. Le premier exemple à suivre montre une séquence de six extensions séparées par des espaces (trois atomes, une balise, un atome et une balise. Le second exemple représente un choix entre deux séquences, l'une contenant un atome et une balise, et l'autre contenant un appel de règle et une balise.
$regle1 = ceci est un {CONTENU-DE-BALISE-1} essai {CONTENU-DE-BALISE-2};
$regle2 = ouvrir {CONTENU-DE-BALISE-1} | $fermer {CONTENU-DE-BALISE-2};
$regle3 = {!{ une balise simple ne nécessitant pas le masquage des caractères { et } }!};
Un élément tag peut être sous-élément direct des éléments item et rule. Le contenu d'un élément tag est de type CDATA .
<rule id="regle1">ceci est un <tag>CONTENU-DE-BALISE-1</tag> essai <tag>CONTENU-DE-BALISE-2</tag> </rule>
<rule id="regle2">
<item> ouvrir <tag>CONTENU-DE-BALISE-1</tag> </item>
<item> <ruleref uri="#fermer"/> <tag>CONTENU-DE-BALISE-2</tag> </item>
Toute extension de règle légale avec un identificateur de langue associé est elle-même une extension de règle légale. La forme ABNF et la forme XML permettent toutes deux d'associer un identificateur de langue légal à tout atome, toute séquence ou tout ensemble de choix (à noter que les appels de règles n'admettent pas d'identificateur de langue). Les syntaxes de la forme ABNF et de la forme XML suivent.
La déclaration de langue d'une extension de règle affecte seulement le contenu de ses constituants. En outre, elle n'affecte que la manipulation des atomes qu'elle contient, et pas les balises ni les appels de règle. L'application de la langue à la manipulation des atomes, notamment pour la recherche de prononciation, est décrite dans le chapitre 2.1.
Par défaut, une grammaire est un document dans une seule langue, dont l'identificateur de langue est fourni par la déclaration de langue dans l'en-tête de la grammaire (cf. le chapitre 4.5). Tous les atomes au sein de cette grammaire seront manipulés, sauf indication contraire, conformément à la langue de la grammaire.
Les situations où les applications s'adressent une communauté d'utilisateurs multilingues nécessiteront peut-être des grammaires avec des mots en plusieurs langues. Par exemple, en réponse à une question telle que : Voulez-vous parler à John Doe ? (une phrase en français avec un nom anglais), la réponse pourra être oui ou bien yes .
La spécification des grammaires de reconnaissance vocale permet à une seule grammaire de rassembler des entrées en plusieurs langues. Elle permet aussi l'utilisation parallèle de plusieurs grammaires, chacune dédiée à une seule langue. Elle permet également qu'un seul énoncé contienne plusieurs langues. Enfin, elle autorise n'importe quelle combinaison des précédents. Par exemple, des grammaires parallèles dont chacune possède des capacités multilingues.
Les agents utilisateurs ne sont pas tous obligés de gérer toutes les langues, ou toutes ou une partie des capacités multilingues. Les conditions de conformité concernant la gestion multilingue par les processeurs grammaticaux XML et ABNF sont traitées respectivement dans le chapitre 5.4 et le chapitre 5.6.
Les applications multilingues doivent relever un défi du même ordre en ce qui concerne le traitement des noms propres (personnes, rues, entreprises, etc.), dont la diction peut emprunter une prononciation ou un accent différents selon la langue d'origine et la langue de locution. Il est souvent impossible de prédire quelle langue les utilisateurs emploieront pour prononcer certains atomes. En effet, les utilisateurs peuvent en fait employer des langues différentes pour les différents mots d'une même phrase, et de façon imprévisible. Par exemple, prenons le nom Robert Jones : un locuteur français pourrait dire Robert avec une prononciation française et Jones avec une prononciation anglaise, tandis qu'un locuteur anglais prononcerait l'ensemble avec une prononciation anglaise.
La portée de la langue : Les déclarations de langues portent localement sur un document et une définition de règle. Dans la terminologie XML, l'attribution de langue se propage en descendant l'arbre du document. Lorsqu'un changement de langue englobe l'appel d'une autre grammaire, la règle appelée et la grammaire qui la contient définissent la langue de l'extension appelée. La langue en vigueur au point d'appel n'a aucun effet sur la règle appelée.
La langue et les résultats : La langue employée pour la reconnaissance d'un atome ne fait pas partie du résultat vocal même si une déclaration de langue est associée à l'atome.
Dans la forme ABNF, on peut accoler à droite un identificateur de langue sur n'importe quelle extension de règle légale, sauf sur un appel de règle. Cette association est constituée par un caractère point d'exclamation ! suivi d'un identificateur de langue légal, sans caractère blanc intermédiaire.
L'association de langue a une priorité plus élevée que celle des séquences ou celles des choix. Pour associer une langue à ces types d'extension de règle, il faut les délimiter par des parenthèses (cf. le chapitre 2.3).
// La langue implicite de la grammaire est l'anglais américain
// Association de langue singulière à des atomes
// Remarquez que "fr-CA" (français canadien) ne s'applique qu'au
// mot oui  à cause des règles de priorité
// Association de langue singulière à une extension
// Manipulation des prononciations du même mot propres aux langues
// Un logiciel de reconnaissance vocal capable écoutera des prononciations
// espagnole mexicaine et anglaise américaine
* Possibles entrées multilingues
Forme XML
Le langage XML 1.0 [XML §2.12] définit l'attribut xml:lang afin d'identifier une langue. L'attribut fournit un seul identificateur de langue pour le contenu de l'élément sur lequel il apparaît. On peut associer un attribut xml:lang aux éléments one-of, token et item. Il applique la manipulation d'atomes sur les atomes dans la portée.
<!-- La langue implicite de la grammaire est l'anglais américain -->
Association de langue singulière à des atomes
"yes" héritage implicite de l'anglais américain
"oui" c'est le français canadien
<!-- Association de langue singulière à une extension -->
Manipulation des prononciations du même mot propres aux langues
Un logiciel de reconnaissance vocale capable écoutera
des prononciations espagnole mexicaine et anglaise américaine.
<!-- Possibles entrées multilingues -->
Ce chapitre définit les règles de priorité de la syntaxe d'extension de règle ABNF. Les documents XML ayant une structure explicite, il n'y a donc pas d'ambiguïté et la définition d'une priorité n'est pas nécessaire. Les définitions de priorité de la forme ABNF ont pour but de limiter le recours aux parenthèses.
Voici le classement prioritaire des extensions de règles. On peut faire appel à des parenthèses pour contrôler explicitement la structure d'une règle.
Un appel de règle, un atome entre guillemets, un atome sans guillemet ou une balise ;
Des parenthèses ( et ) pour le regroupement et des crochets [ et ] pour le regroupement optionnel ;
L'opérateur de répétition (par exemple, <0-1>) et l'association de langue (par exemple, !en-AU ) s'appliquent à l'extension de règle immédiatement précédente. (Pour les appliquer à une séquence ou à des choix, regroupez-les avec des parenthèses ou des crochets) ;
Une séquence d'extensions de règles ;
Un ensemble de choix d'extensions de règles, séparés par des caractères barre verticale | , avec des poids optionnels.
Inutile. La structure XML est explicite.
3.1 La définition de règle élémentaire
Une définition de règle associe une extension de règle légale au nom d'une règle. La définition de règle est également chargée d'en définir la portée : est-elle locale à la grammaire où elle est définie, ou bien peut-on l'appeler depuis d'autres grammaires ? Enfin, la définition de règle peut inclure des commentaires de documentation et d'autres aspects pratiques.
Le nom de règle de chaque définition de règle doit être unique au sein de la grammaire. On peut se servir du même nom de règle dans plusieurs grammaires.
Une définition de règle est référencée dans un appel de règle par une adresse URI, le nom de règle apparaissant comme identificateur de fragment.
Le but principal d'une définition de règle est d'associer une extension de règle légale à un nom de règle.
Un nom de règle légal dans les formes XML et ABNF se compose d'une séquence de caractères qui :
Est un nom XML [XML §2.3], et ;
Ne contient pas de caractères point . ni deux-points : ni tiret - , et ;
N'est pas le nom d'une règle spéciale ( NULL , VOID , GARBAGE ).
Les noms de règles définis doivent être uniques au sein d'une grammaire. Le schéma fait valoir ce point en déclarant les noms de règles avoir le type XML ID .
Les noms de règles sont sensibles à la casse dans les grammaires XML et ABNF. On utilise une comparaison de chaînes exacte pour résoudre les appels de noms de règles.
Un nom de règle légal ne peut pas être le nom d'une des règles spéciales, à savoir NULL , VOID ou GARBAGE .
La définition de règle se compose d'une déclaration de portée optionnelle (expliquée dans la section suivante), suivie d'un nom de règle légal, d'un signe égal, d'une extension de règle légale, et enfin d'un caractère point-virgule. La définition de règle prend l'une des formes légales suivantes :
$nomDeRegle = extensionDeRegle;
public $nomDeRegle = extensionDeRegle;
private $nomDeRegle = extensionDeRegle;
$ville = Boston | "New York" | Madrid;
$commande = $action $objet;
Une définition de règle vide est illégale.
Il est légal de définir une règle se développant en parenthèses vides ou en règle $NULL (formes équivalentes), tout comme définir une règle se développant en un seul élément tag.
$regle = ();
$regle = $NULL;
$regle = ;
Une définition de règle est représentée par l'élément rule. L'attribut id de l'élément indique le nom de la règle, qui doit être unique au sein de la grammaire (cet aspect est imposé par le langage XML). Le contenu de l'élément rule peut être n'importe quelle extension de règle légale définie dans le chapitre 2. L'attribut scope est expliqué dans la section suivante.
<rule id="ville">
<rule id="commande">
<ruleref uri="#objet"/>
Il est illégal de définir un élément rule vide ou contenant seulement des caractères blancs de type CDATA .
Il est légal de définir un élément rule se développant en un élément item vide, ou en un seul appel de règle NULL.
Il est légal de définir une règle se développant en un seul élément tag.
<!-- Légal -->
<rule id="regle"><item/></rule>
<rule id="regle"><ruleref special="NULL"/></rule>
<!-- ILLÉGAL -->
<rule id="regle"/>
<rule id="regle"></rule>
<rule id="regle">   </rule>
Chaque règle définie a une portée qui est soit de type private , soit de type public . Si elle n'est pas déclarée explicitement dans la définition de règle, la portée est alors implicitement de type private .
On peut appeler explicitement une règle à portée publique (en utilisant la syntaxe d'identificateur de fragment des adresses URI) dans les définitions de règles d'autres documents de grammaire ou d'autres documents qui ne sont pas des grammaires. On ne peut pas appeler une règle à portée privée ainsi, et elle n'est directement accessible qu'au sein de la grammaire qui la contient. Une règle privée n'est explicitement appelable que par les autres règles de la même grammaire.
Pour information, les auteurs de grammaires peuvent s'inspirer du guide suivant pour déterminer la portée des règles d'une grammaire :
La création d'une grammaire présente beaucoup de points communs avec la programmation. Établir les contrats d'une interface de programmation (API) est analogue à définir un ensemble de grammaires et à définir les règles publiques d'une grammaire dont chacune a un comportement linguistique défini.
La conception et la mise en œuvre cohérentes des règles publiques favorisent la réutilisation des grammaires et permettent de constituer facilement des bibliothèques de grammaires.
Les grammaires en langue naturelle nécessitent souvent de fabriquer nombre de règles de fonctionnement internes pour créer un nombre moindre de règles externes utiles. Dissimuler les règles de fonctionnement d'une grammaire en privatisant la portée permet de les faire évoluer sans affecter les autres grammaires qui l'appellent. Dissimuler les règles de fonctionnement permet également de prévenir la mauvaise utilisation accidentelle de l'une d'elles.
La compilation d'une grammaire ressemble à celle d'un langage de programmation. Rendre les règles privées permet aux compilateurs grammaticaux évolués de réaliser des optimisations qui seraient inapplicables sur une règle déclarée publique.
On peut annoter une définition de règle avec les mots-clés public ou private . Si la portée est absente, la définition sera alors implicitement de type private .
$commune = Townsville | Beantown;
private $ville = Boston | "New York" | Madrid;
public $commande = $action $objet;
L'attribut scope de l'élément rule définit la portée de la définition de règle. Les valeurs admises sont "public" et "private". Si non indiquée, la portée vaudra implicitement "private".
<rule id="commune">
<rule id="ville" scope="private">
<rule id="commande" scope="public">
Il est souvent souhaitable d'inclure des exemples de phrases correspondant aux définitions de règles avec elles. Quelle que soit la définition de règle, on peut lui fournir zéro, un ou plusieurs exemples de phrases. Puisque les exemples sont balisés explicitement comme tels, on peut mettre à profit des outils automatiques pour réaliser des tests de régression et pour générer une documentation de la grammaire.
Un commentaire de documentation est un commentaire dans le style des langages C/C++/Java, commençant par la séquence de caractères /** et précédant immédiatement la définition de règle en question. Zéro à plusieurs balises @example peuvent être contenues à la fin du commentaire de documentation. La syntaxe obéit au style paragraphe balisé (N.d.T. Tagged Paragraph) des commentaires de documentation du langage de programmation Java [JAVA §18.4]. L'atomisation de l'exemple obéit aux règles d'atomisation et de séquence définies dans le chapitre 2.1 et le chapitre 2.3 respectivement.
* Une directive simple d'exécution d'une action.
* @example ouvrir la fenêtre
* @example fermer la porte
On peut fournir un nombre quelconque d'éléments example comme contenu initial d'un élément rule. L'atomisation de l'exemple obéit aux règles d'atomisation et de séquence définies dans le chapitre 2.1 et le chapitre 2.3 respectivement.
<!-- Une directive simple d'exécution d'une action. -->
<example> ouvrir la fenêtre </example>
<example> fermer la porte </example>
Un document de grammaire autonome conforme se compose d'une en-tête légale, suivie d'un corps constitué d'un ensemble de définitions de règles légales. Toutes les règles définies au sein de cette grammaire ont une portée encadrée par l'espace de nommage des noms de règles de la grammaire, et chaque nom de règle doit être légal et unique.
Il est légal pour une grammaire de ne pas définir de règle. La grammaire ne peut pas servir au traitement d'une entrée puisqu'elle ne définit aucun motif pour filtrer l'entrée de l'utilisateur.
Une en-tête de grammaire autonome légale se compose d'un certain nombre de déclarations obligatoires ou optionnelles. En outre, la forme ABNF et la forme XML ont chacune des besoins et des caractéristiques d'en-tête spécifiques à leur forme syntaxique. Le rangement des déclarations d'en-tête est également propre à chaque forme.
Le tableau résume les informations déclarées dans une en-tête de grammaire et leurs représentations adéquates dans la forme ABNF et la forme XML.
Déclaration Statut Forme ABNF Forme XML
Version de la grammaire Obligatoire §4.2 : en-tête auto-identifiante ABNF §4.3 : attribut version sur l'élément grammar
Espace de nommage XML Obligatoire (XML uniquement) Sans objet §4.3 : attribut xmlns sur l'élément grammar
Type de document Recommandé (XML uniquement) Sans objet §4.3 : déclaration DOCTYPE XML
Codage des caractères Recommandé §4.4 : en-tête auto-identifiante ABNF §4.4 : attribut encoding dans la déclaration XML
Langue Obligatoire en mode voix (voice)
Ignoré en mode DTMF (dtmf) §4.5 : déclaration language §4.5 : attribut xml:lang sur l'élément grammar
Mode Optionnel §4.6 : déclaration mode §4.6 : attribut mode sur l'élément grammar
Règle racine Optionnel §4.7 : déclaration root §4.7 : attribut root sur l'élément grammar
Format de balise Optionnel §4.8 : déclaration tag-format §4.8 : attribut tag-format sur l'élément grammar
Adresse URI de base Optionnel §4.9 : déclaration base §4.9 : attribut xml:base sur l'élément grammar
Lexique de prononciation Optionnel. Plusieurs sont permis. §4.10 : déclaration lexicon §4.10 : élément lexicon
Métadonnées Optionnel. Plusieurs sont permises. §4.11.1 : déclarations meta et http-equiv §4.11.1 : élément meta
Métadonnées XML Optionnel. (XML uniquement) Sans objet §4.11.2 : élément metadata
Balise Optionnel. Plusieurs sont permises. §4.12 : déclaration tag §4.12 : élément tag
Une grammaire se prévalant de cette spécification doit déclarer une valeur de version de "1.0".
Remarque : La version de la grammaire indique la version de la spécification mise en œuvre, elle ne sert pas pour le versionnage du contenu de la grammaire. On peut utiliser une déclaration meta, ou metadata, pour le versionnage du contenu.
Forme ABNF : Résumé de l'en-tête
L'en-tête légale d'un document ABNF autonome se compose d'une en-tête auto-identifiante ABNF obligatoire, comprenant la version de la grammaire et un codage de caractères optionnel, suivie dans un ordre quelconque par les déclarations suivantes :
La règle racine
Le format des balises
L'adresse URI de base
Un ou plusieurs lexiques de prononciation (un nombre quelconque)
Une ou plusieurs déclarations meta et http-equiv (un nombre quelconque)
Une ou plusieurs balises (un nombre quelconque)
Des commentaires ABNF peuvent se loger entre les déclarations de l'en-tête ABNF, après l'en-tête auto-identifiante ABNF.
Les déclarations d'en-tête sont suivies par les définitions de règles de la grammaire.
Voici deux exemples d'en-têtes ABNF. Remarquez que l'ordre des déclarations (sauf l'en-tête auto-identifiante ABNF) n'est pas significatif.
// Une grammaire française canadienne
// C'est une grammaire vocale
// Voici la règle racine
root $VillesDuQuebec;
Forme XML : Résumé de l'en-tête
Un document de grammaire de forme XML autonome se compose de :
Un prologue XML légal ;
Un élément grammar racine doté des attributs suivants :
L'espace de nommage XML
Les attributs du schéma XML
Un élément grammar contenant dans n'importe quel ordre un nombre quelconque d'éléments suivants :
Une ou plusieurs métadonnées (un nombre quelconque)
Les définitions de règle obéissent aux déclarations lexicon, meta, metadata et tag.
Voici des exemples d'en-têtes de grammaire de forme XML, chacune contenant toutes les déclarations permises sur l'élément grammar et l'une avec une déclaration DOCTYPE :
root="maRegle"
xml:base="http://www.example.com/chemin-vers-fichier-de-base">
root="VillesDuQuebec"
xml:base="http://www.example.com/autre-chemin-vers-fichier-de-base">
L'en-tête auto-identifiante ABNF doit être présente dans tous les documents de grammaire de forme ABNF autonomes légaux.
Le premier caractère d'un document ABNF doit être un symbole dièse # (x23), à moins qu'une marque d'ordre des octets XML 1.0 [XML §4.3.3] optionnelle ne le précède. La marque d'ordre des octets ABNF obéit aux définitions et contraintes du langage XML. Par exemple, les documents codés en UTF-16 doivent commencer par une marque d'ordre des octets.
La marque d'ordre des octets optionnelle et le symbole dièse obligatoire doivent être suivis immédiatement et exactement de la chaîne ABNF (x41 x42 x4d x46), ou l'équivalent approprié dans le codage du document (par exemple, pour un codage petit boutien UTF-16, ce sera x23 x00 x41 x00 x42 x00 x4d x00 x46 x00 ). Si la marque d'ordre des octets est absente dans une grammaire codée en UTF-16, alors le processeur grammatical devrait effectuer une auto-détection du codage de caractères de façon analogue à celle définie dans la spécification XML [XML §F].
Viennent ensuite un seul caractère espace (x20) et le numéro de version obligatoire, c'est-à-dire 1.0 (x31 x2e x30) pour cette spécification.
Suit un codage de caractères optionnel. Le chapitre 4.4 définit plus précisément les codages de caractères. Si le codage de caractères est présent, il doit y avoir un seul caractère espace (x20) entre le numéro de version et lui.
L'en-tête auto-identifiante se termine par un caractère point-virgule (x3b) suivi immédiatement d'un caractère saut de ligne. Le point-virgule doit être le premier caractère à suivre le numéro de version ou, le cas échéant, le codage de caractères.
Les caractères blancs ne sont pas significatifs pour le reste des déclarations de l'en-tête ABNF.
Un document de grammaire de forme XML autonome légal doit avoir un prologue XML [XML §2.8].
Le prologue XML d'une grammaire de forme XML comprend la déclaration XML et une déclaration DOCTYPE optionnelle indiquant la définition DTD de la grammaire. Il est suivi par l'élément racine grammar. Le prologue XML peut également contenir des commentaires XML, des instructions de traitement et autres contenus permis par XML dans le prologue.
Le numéro de version de la déclaration XML indique la version du langage XML employé. Le numéro de version de l'élément grammar indique la version de la spécification des grammaires employée (c'est-à-dire 1.0 pour cette spécification). La version de grammaire est un attribut obligatoire.
L'élement grammar doit indiquer l'espace de nommage de la grammaire. On y parvient en déclarant un attribut xmlns ou un attribut préfixé par xmlns . Cf. le document [XMLNS] pour des précisions. Remarquez que si l'attribut xmlns est utilisé seul, il fixe l'espace de nommage implicite de l'élément sur lequel il apparaît et tous ses sous-éléments. L'espace de nommage des grammaires de forme XML est le suivant : http://www.w3.org/2001/06/grammar.
On recommande que l'élément grammar indique également l'emplacement du schéma de grammaire (cf. l'annexe C) via l'attribut xsi:schemaLocation défini dans [SCHEMA1]. Quoique non obligatoire, tous les exemples de ce document le mentionnent afin d'en encourager l'usage :
Si présente, la déclaration DOCTYPE optionnelle doit appeler la déclaration de type de document et l'identificateur normalisés suivants :
Le codage de caractères apparaît dans la déclaration XML comme défini par la spécification XML. Cf. le chapitre 4.4 pour des précisions.
La langue est définie par l'attribut xml:lang sur l'élément grammar. Cf. le chapitre 4.5 pour des précisions.
Le mode de la grammaire est défini par l'attribut mode sur l'élément grammar. Cf. le chapitre 4.6 pour des précisions.
La règle racine est définie par l'attribut root sur l'élément grammar. Cf. le chapitre 4.7 pour des précisions.
Le format des balises est défini par l'attribut tag-format sur l'élément grammar. Cf. le chapitre 4.8 pour des précisions.
L'adresse URI de base du document est définie par l'attribut xml:base sur l'élément grammar. Cf. le chapitre 4.9 pour des précisions.
La déclaration de codage de caractères indique le système employé pour coder les données textuelles dans le document. Par exemple, pour des applications américaines, il est courant d'utiliser les codages US-ASCII, UTF-8 (Unicode 8-bit) ou ISO-8859-1. Les grammaires japonaises sont censées utiliser des codages de caractères tels que EUC-JP et UTF-16 (Unicode 16-bit).
Hormis une représentation syntaxique différente, la forme ABNF suit la gestion du codage de caractères définie pour le langage XML. Les processeurs grammaticaux de forme XML doivent accepter les deux codages UTF-8 et UTF-16 de la norme ISO/IEC 10646, et ils peuvent gérer d'autres codages de caractères. Cette obligation découle du fait qu'un processeur grammatical de forme XML est avant tout un processeur XML conforme qui est tenu, à ce titre, de gérer ces codages de caractères. Pour la cohérence, les processeurs grammaticaux de forme ABNF doivent également accepter les deux codages UTF-8 et UTF-16, et ils peuvent gérer d'autres codages de caractères.
Pour les deux formes de grammaire, quoique optionnelle, la déclaration du codage de caractères est fortement recommandée. Le langage XML définit le comportement des processeurs XML face à un document XML sans déclaration de codage de caractères. Pour la cohérence, les processeurs grammaticaux de forme ABNF doivent adopter le même comportement (avec les ajustements appropriés pour tenir compte des différences syntaxiques). (Remarquez que la déclaration de codage de caractères n'est optionnelle que si elle l'est aussi pour le document XML légal).
La déclaration de codage de caractères fait partie de l'en-tête de grammaire auto-identifiante définie dans le chapitre 4.1 et son traitement a lieu en combinaison, le cas échéant, avec la marque d'ordre des octets, en suivant la même procédure que celle définie par la spécification XML 1.0 [XML §4.3.3].
Voici des exemples d'en-têtes de grammaire auto-identifiantes ABNF, avec et sans déclaration de codage de caractères.
Remarque : La forme ABNF ne propose aucune syntaxe d'appel de caractère pour saisir un caractère particulier, par exemple, pour un caractère non accessible directement avec les périphériques d'entrée disponibles. À comparer avec la syntaxe d'appel de caractère XML 1.0 [XML §4.1]. La forme XML de la spécification est recommandée pour les développements nécessitant des appels de caractères.
La forme XML déclare le codage de caractères dans la déclaration XML à la première ligne du document.
Voici des exemples d'en-têtes XML, avec et sans déclaration de codage de caractères :
La déclaration de langue d'une grammaire fournit l'identificateur de langue indiquant la langue principale du contenu du document et, en option, un pays ou une autre variante. En outre, on peut étiqueter un identificateur de langue sur n'importe quelle extension de règle légale.
La déclaration de langue est obligatoire pour toutes les grammaires de reconnaissance vocale, c'est-à-dire toutes les grammaires avec un attribut mode valant "voice". (Remarquez que l'attribut mode vaut par défaut "voice", en absence de déclaration de mode explicite dans la forme ABNF, ou d'attribut mode dans la forme XML).
Si une grammaire de la forme XML est incorporée à un autre document XML, par exemple, comme le fait VoiceXML 2.0, alors l'attribut xml:lang est optionnel sur l'élément grammar, et l'attribut xml:lang doit hériter sa valeur du document englobant.
Dans les grammaires DTMF, la déclaration de langue doit être ignorée si présente.
La définition de conformité dans le chapitre 5 prévoit le comportement d'un processeur grammatical lorsqu'il rencontre une variante de langue non gérée.
L'en-tête ABNF doit contenir zéro ou une seule déclaration de langue. Elle se compose du mot-clé language , suivi d'un caractère blanc puis d'un identificateur de langue légal puis d'un caractère blanc optionnel et enfin d'un caractère point-virgule ; de terminaison.
Selon la spécification XML 1.0 [XML §2.12], l'identificateur de langue est indiqué par un attribut xml:lang sur l'élément racine grammar.
Le mode d'une grammaire indique le type d'entrée que l'agent utilisateur devrait détecter. La valeur implicite du mode est "voice" pour les grammaires de reconnaissance vocale. Une autre valeur de mode d'entrée est définie dans l'annexe E, à savoir la valeur "dtmf".
L'attribut mode indique comment interpréter les atomes contenus dans la grammaire. Les atomes vocaux sont censés être détectés comme des signaux vocaux électro-acoustiques sonnant comme les atomes en question. Le comportement pour une entrée DTMF, si prise en charge, est défini dans l'annexe E.
Souvent, pour détecter les tonalités DTMF, on utilisera un agent utilisateur différent de celui servant pour la reconnaissance vocale. Ce sera peut-être le cas pour les autres modes définis dans les révisions futures de la spécification.
La spécification ne définit aucun mécanisme qui permette à une seule grammaire de mélanger des modes, c'est-à-dire que la représentation d'une grammaire mixte "voice" et "dtmf" n'est pas définie. En outre, il est illégal qu'un appel de règle dans une grammaire donnée indique une autre grammaire de mode différent.
Toutefois, un agent utilisateur peut prendre en charge l'activation simultanée de plusieurs grammaires dont des grammaires "voice" et des grammaires "dtmf". C'est nécessaire, par exemple, pour les navigateurs VoiceXML équipés pour une entrée DTMF [VXML2]. (Remarque : Une activation parallèle implique une disjonction au niveau racine des grammaires plutôt qu'un mélange des modes au sein de la structure des grammaires.)
L'en-tête ABNF doit contenir zéro ou une seule déclaration de mode. Elle se compose du mot-clé mode , suivi d'un caractère blanc puis de voice , ou bien de dtmf , puis d'un caractère blanc optionnel et enfin d'un caractère point-virgule ; de terminaison. Si l'en-tête ABNF ne déclare aucun mode, alors il vaudra implicitement "voice".
La déclaration de mode est fournie par un attribut mode optionnel sur l'élément racine grammar. Les valeurs légales sont "voice" et "dtmf". Si l'attribut mode est absent, alors le mode vaut implicitement "voice".
Les formes XML et ABNF permettent toutes deux en option de déclarer dans l'en-tête de grammaire une seule règle comme règle racine de la grammaire. La règle déclarée racine doit être définie dans la portée de la grammaire. On peut la déclarer à portée publique ("public) ou bien privée ("private").
L'appel implicite de la règle racine d'une grammaire est légal. La syntaxe d'appel implicite d'une règle racine est définie dans le chapitre 2.2. Appeler implicitement une grammaire par sa racine si cette grammaire ne déclare pas de règle racine légale constitue une erreur.
Quoique la déclaration d'une règle racine ne soit pas obligatoire, c'est une bonne pratique d'en déclarer une pour toute grammaire.
L'en-tête ABNF doit contenir zéro ou une seule déclaration de règle racine. Elle se compose du mot-clé root , suivi d'un caractère blanc puis du nom de règle légal d'une règle définie dans la grammaire, préfixé par un signe dollar $ , puis d'un caractère blanc optionnel et enfin d'un caractère point-virgule ; de terminaison. Si l'en-tête ABNF ne déclare pas de règle racine, alors il est illégal d'appeler implicitement la grammaire par sa racine.
root $nomDeRegle;
La déclaration du nom de la règle racine est donnée par un attribut root optionnel sur l'élément grammar. La déclaration racine doit identifier une règle définie ailleurs au sein de la même grammaire. La valeur de l'attribut root est du type XML IDREF (ce n'est pas une adresse URI) et elle ne doit pas inclure de signe dièse # .
<grammar root="nomDeRegle" ...>
La déclaration optionnelle tag-format définit un identificateur de format de balise indiquant le type de contenu de toutes les balises de règles et balises d'en-têtes présentes dans une grammaire.
L'identificateur de format de balise est une adresse URI. On recommande que le format de balise indique à la fois le type de contenu et une version. Les balises ont habituellement un contenu prévu pour un processeur d'interprétation sémantique et, si présent, l'identificateur devrait indiquer quel processeur utiliser.
Les valeurs d'identificateurs de formats commençant par la chaîne semantics/x.y (où x et y sont des chiffres) sont réservées pour la spécification L'interprétation sémantique de la reconnaissance vocale du W3C [SEM] ou ses versions futures.
La prise en charge des balises par les processeurs grammaticaux n'est pas définie si la déclaration de format de balise est absente.
L'en-tête ABNF doit contenir zéro ou une seule déclaration de format de balise. Elle se compose du mot-clé tag-format , suivi d'un caractère blanc puis d'un identificateur de format de balise (une adresse URI) puis d'un caractère blanc et enfin d'un caractère point-virgule ; de terminaison.
Exemple informatif ("semantics/1.0" est un identificateur réservé) :
L'attribut optionnel tag-format sur l'élément grammar contient un identificateur de format de balise.
Les adresse URI relatives se résolvent par rapport à une adresse URI de base pouvant provenir de plusieurs sources. La déclaration d'adresse URI de base permet aux auteurs de définir explicitement l'adresse URI de base d'un document. Cf. le chapitre 4.9.1 pour des précisions concernant la résolution des adresses URI relatives.
L'information de chemin définie par la déclaration d'adresse URI de base affecte seulement les adresses URI du document où l'élément apparaît.
La déclaration d'adresse URI de base est possible mais optionnelle dans les deux formes XML et ABNF.
Remarque : L'adresse URI de base peut être définie dans une déclaration meta mais on recommande une déclaration de base explicite pour les deux formes ABNF et XML.
L'en-tête ABNF doit contenir zéro ou une seule déclaration d'adresse URI de base. Elle se compose du mot-clé base , suivi d'un caractère blanc puis d'une adresse URI ABNF puis d'un caractère blanc optionnel et enfin d'un caractère point-virgule ; de terminaison.
base <http://www.example.com/chemin-du-fichier-de-base>;
base <http://www.example.com/autre-chemin-de-fichier-de-base>;
La déclaration de l'adresse URI de base suit la spécification [XML-BASE], et elle est indiquée par un attribut xml:base sur l'élément racine grammar.
xml:base="http://www.example.com/chemin-du-fichier-de-base"
xml:base="http://www.example.com/autre-chemin-de-fichier-de-base"
Les agents utilisateurs doivent calculer l'adresse URI de base pour résoudre les adresses URI relatives conformément au document [RFC2396]. Voici comment appliquer le document RFC 2396 aux documents de grammaire.
Les agents utilisateurs doivent établir l'adresse URI de base selon l'ordre de priorité suivant (de la priorité la plus élevée à la plus faible) :
L'adresse URI de base est fixée par l'attribut xml:base sur l'élément grammar, ou par la déclaration base dans l'en-tête ABNF (cf. chapitre 4.9) ;
L'adresse URI de base est fournie par une déclaration meta ;
L'adresse URI de base est donnée par les métadonnées révélées au cours d'un échange protocolaire telle qu'une en-tête HTTP (cf. le document [RFC2616]) ;
À défaut, l'adresse URI de base est celle du document courant. Les documents de grammaire n'ont pas tous une adresse URI de base (par exemple, un document de grammaire valide peut apparaître dans un courier électronique sans être désigné par une adresse URI). Ces documents de grammaire ne sont pas valides s'ils contiennent des adresses URI relatives qui s'appuient sur une adresse URI de base.
Une grammaire peut en option appeler un ou plusieurs documents de lexique de prononciation externes. Un document de lexique est identifié par une adresse URI avec un type de média optionnel.
Les informations de prononciation contenues dans un document lexique servent uniquement aux atomes définis dans la grammaire englobante.
Le groupe de travail Voice Browser du W3C développe actuellement le langage de balisage de lexiques de prononciation [LEX]. Cette spécification définira le processus de correspondance entre les atomes et les entrées du lexique, et le mécanisme selon lequel un logiciel de reconnaissance vocale manipulera les prononciations multiples provenant de lexiques internes et de ceux définis par les grammaires. La gestion de la prononciation par des formats de lexiques propriétaires dépendra forcément du logiciel de reconnaissance vocale.
Les lexiques de prononciation sont nécessairement spécifiques de la langue. La recherche de prononciation dans un lexique et l'inférence de prononciation pour un atome peuvent utiliser un algorithme spécifique de la langue. (Cf. le chapitre 2.1 pour d'autres renseignements sur la manipulation des atomes et leurs prononciations.)
L'en-tête ABNF peut contenir un nombre quelconque (zéro, un ou plus) de déclarations de lexiques de prononciation. Une déclaration de lexique se compose du mot-clé lexicon , suivi d'un caractère blanc puis d'une adresse URI ABNF, avec un type de média ou sans, puis d'un caractère blanc optionnel et enfin d'un caractère point-virgule ; de terminaison. (Notez qu'aucun signe $ ne précède l'adresse URI d'un lexique, au contraire des appels de règle ABNF). Exemple :
lexicon <http://www.example.com/lexique.fichier>;
lexicon <http://www.example.com/noms-de-ville-curieux.fichier>~<type-media>;
Il peut apparaître un nombre quelconque d'éléments lexicon comme sous-éléments immédiats de l'élément grammar. L'élément lexicon doit avoir un attribut uri indiquant l'adresse URI identifiant l'emplacement du document de lexique de prononciation.
L'élément lexicon peut avoir un attribut type indiquant le type de média du document de lexique de prononciation.
<lexicon uri="http://www.example.com/lexique.fichier"/>
<lexicon uri="http://www.example.com/noms-de-ville-curieux.fichier" type="type-media"/>
Les documents de grammaire permettent aux auteurs d'indiquer de plusieurs façons des métadonnées, c'est-à-dire des informations à propos du document et non son contenu.
On peut utiliser une déclaration meta dans la forme ABNF et la forme XML pour exprimer des métadonnées dans les grammaires des deux types ou pour appeler les métadonnées disponibles dans une ressource externe. La forme XML dispose également de l'élément metadata offrant un traitement des métadonnées plus général et plus puissant que meta. Puisque l'élément metadata impose un schéma de métadonnées XML non exprimable dans ABNF, il n'existe donc aucun équivalent dans les grammaires de forme ABNF.
Une déclaration meta dans la forme ABNF ou XML associe une chaîne à une propriété meta déclarée, ou bien déclare un contenu de type http-equiv .
La propriété seeAlso est le seul nom de propriété meta défini. Elle sert à désigner une ressource susceptible de fournir d'autres métadonnées à propos de la grammaire contenante. Cette propriété est modelée sur la propriété rdfs:seeAlso de la spécification du schéma du cadre de description de ressources (RDF) 1.0 [RDF-SCHEMA §2.3.4].
En ce qui concerne les propriétés de métadonnées générales, on recommande aux auteurs de grammaires d'utiliser celles définies par l' Initiative de métadonnées Dublin Core [DC]. Par exemple, utiliser les mots-clés Creator pour identifier l'entité principale responsable de la création du contenu de la grammaire, Date pour indiquer la date de création, ou encore Source pour désigner la ressource de laquelle découle la grammaire (par exemple, utiliser Source pour indiquer l'adresse URI du document original lors de la conversion d'une grammaire de forme XML en une grammaire de forme XML).
L'en-tête ABNF peut contenir un nombre quelconque (zéro, un ou plus) de déclarations meta et de déclarations http-equiv. Chaque déclaration se compose du mot-clé meta ou http-equiv , suivi d'un caractère blanc puis de la chaîne du nom entre guillemets puis du mot-clé is puis d'un caractère blanc puis de la chaîne de contenu entre guillemets puis d'un caractère blanc optionnel et enfin d'un caractère point-virgule ; de terminaison.
La chaîne de nom et la chaîne de contenu doivent être délimitées par une paire correspondante de guillemets doubles " ou de guillemets simples ' .
Exemple informatif :
Une propriété de métadonnée se déclare avec un élément meta. Un attribut name ou bien http-equiv est obligatoire. La présence des deux attributs en même temps est illégale. Un attribut content est également obligatoire. Les éléments meta, metadata et lexicon doivent apparaître avant tous les éléments rule contenus dans l'élément racine grammar. L'ordre d'apparition des éléments meta, metadata et lexicon n'est pas significatif.
L'élément metadata est un conteneur dans lequel on peut placer les informations concernant le document en utilisant un schéma de métadonnées. Quoique n'importe quel schéma de métadonnées puisse convenir pour l'élément metadata, on recommande d'utiliser le schéma du cadre de description de ressources (RDF) [RDF-SCHEMA] avec les propriétés de métadonnées générales définies par l'initiative de métadonnées Dublin Core [DC].
Le langage RDF est déclaratif et il fournit une méthode normalisée permettant d'utiliser le langage XML pour représenter des métadonnées sous forme de déclarations à propos des propriétés et des relations des éléments sur le Web. Les créateurs de contenus devraient consulter les recommandations de métadonnées du W3C [RDF-SYNTAX] et [RDF-SCHEMA] pour décider quel schéma RDF de métadonnées utiliser dans leurs documents. Ils devraient également consulter l'initiative de métadonnées Dublin Core [DC], qui constitue un ensemble fondamental de propriétés de métadonnées d'utilisation générale (par exemple, Title , Creator , Subject , Description , Copyrights , etc.).
Cette spécification définit seulement la représentation XML de cette forme de déclaration de métadonnées. Il n'existe pas d'équivalent ABNF de l'élément metadata. La conversion d'une grammaire de forme XML en une grammaire de forme ABNF peut extraire et placer les données XML dans un document séparé, appelé ensuite par une déclaration de métadonnées seeAlso dans le document ABNF. Remarque : Un agent recherchant des métadonnées RDF dans des documents XML ne pourrait pas les trouver même si elles étaient représentées en ABNF. C'est la raison pour laquelle la prise en charge RDF dans ABNF a été jugée peu utile.
Les propriétés de document déclarées avec l'élément metadata peuvent utiliser n'importe quel schéma de métadonnées. Les éléments metadata, meta et lexicon doivent apparaître avant tous les éléments rule contenus dans l'élément racine grammar. L'ordre d'apparition des éléments metadata, meta et lexicon n'est pas significatif.
Informatif : Voici un exemple montrant comment placer un élément metadata dans un document de grammaire XML en utilisant le schéma RDF Dublin Core version 1.0 [DC], qui décrit les informations générales à propos du document tels que le titre, la description, la date, et ainsi de suite :
<!-- Métadonnées à propos du document de grammaire -->
Une grammaire peut indiquer en option une ou plusieurs déclarations tag dans l'en-tête. Le contenu d'un élément tag dans l'en-tête, comme celui d'une balise dans une extension de règle, est une chaîne arbitraire susceptible d'interprétation sémantique.
L'en-tête ABNF peut contenir un nombre quelconque (zéro, un ou plus) de déclarations de balises.
La déclaration de balise se compose d'une chaîne délimitée comme décrit dans 2.6 La forme ABNF, suivie d'un caractère point-virgule ; de terminaison.
Le contenu de la balise est constitué par tout le texte entre les délimiteurs ouvrant et fermant, y compris les caractères blancs de tête et de queue. Le contenu de la balise n'est pas analysé par le processeur grammatical.
{CONTENU-DE-BALISE-1};
{!{CONTENU-DE-BALISE-2}!};
$regle = ...;
L'élément grammar admet un nombre quelconque d'éléments tag comme sous-éléments immédiats. Le contenu d'un élément tag est de type CDATA .
<tag>CONTENU-DE-BALISE-1<tag>
<tag>CONTENU-DE-BALISE-2<tag>
Les commentaires peuvent se place un peu partout dans un document de grammaire. Pour la forme XML, utilisez des commentaire XML. Pour la forme ABNF, il existe des commentaires de documentation et des commentaires de style C/C++/Java.
Les commentaires C/C++/Java sont permis. Les commentaires de documentation sont permis avant les déclarations grammar et language, et avant toute définition rule.
Le chapitre 3.3 définit le format pour représenter les exemples dans les commentaires de documentation avant une définition de règle.
// Commentaire sur une ligne de style C++/Java
/* Commentaire de style C/C++/Java */
/** Commentaire de documentation de style Java */
La syntaxe d'un commentaire XML est la suivante :
Le comportement de récupération et de mise en cache des documents de grammaires des formes ABNF et XML est déterminé principalement par l'environnement où opère le processeur grammatical. Par exemple, les recommandations VoiceXML 1.0 et VoiceXML 2.0 définissent certains comportements de récupération et de mise en cache qui s'appliquent aux grammaires activées par un navigateur VoiceXML. De même, toute interface de programmation (API) d'un logiciel de reconnaissance utilisant des grammaires de formes ABNF ou XML peut présenter un comportement de récupération et de mise en cache.
Pour déterminer la fraîcheur des documents, on recommande que les processeurs grammaticaux respectent l'interprétation suivante pour la restitution de la grammaire.
L'activation d'une grammaire est le point depuis lequel le logiciel de reconnaissance commence la détection de l'entrée d'utilisateur pour la comparer à la grammaire, et elle correspond donc à l'action de restitution visuelle ou sonore de la sortie du système. Comme pour la restitution de la sortie, la fraîcheur de la grammaire devrait être vérifiée près du moment de l'activation de la grammaire.
Les mots-clés ABNF sont sensibles à la casse. Les mots-clés du langage ABNF ne sont pas réservés. Voici ceux dont la signification est définie dans ABNF :
Déclaration de la langue language
Déclaration du mode mode
Déclaration de la racine root
Déclaration du format des balises tag-format
Déclaration de l'adresse URI de base base
Lexique de prononciation lexicon
Déclarations meta ou http-equiv meta, http-equiv, is
Définition de règle public, private
Puisque les mots-clés ne sont pas réservés, ils peuvent servir comme noms de règles ou comme atomes. Voici une grammaire légale acceptant en entrée une séquence d'un ou plusieurs atomes publics :
Ce chapitre est normatif.
Plusieurs jeux de critères de conformité des grammaires existent :
Un fragment de document de grammaire de forme XML est un fragment de grammaire de forme XML conforme si :
C'est un document XML bien formé [XML] conformément aux espaces de nommage dans XML [XMLNS] ;
Et c'est un document respectant les critères définis pour les documents de grammaire de forme XML autonomes conformes après que :
Tous les éléments et attributs des espaces de nommage non grammaticaux ainsi que tous les attributs xmlns qui se rapportent à des éléments appartenant à des espaces de nommage non grammaticaux ont été retirés du document, et ;
Une déclaration XML appropriée (c'est-à-dire, <?xml...?> ) a été placée au début du document, et ;
Si l'élément grammar n'indique pas déjà l'espace de nommage de la grammaire par un attribut xmlns, alors la déclaration xmlns="http://www.w3.org/2001/06/grammar" a été ajoutée à cet élément grammar.
Un document est un document de grammaire de forme XML autonome conforme s'il satisfait aux conditions suivantes :
C'est un document XML valide qui adhère à la présente spécification ( La spécification des grammaires de reconnaissance vocale ), y compris aux contraintes exprimées dans le schéma (cf. l'annexe C), et qui possède un prologue de forme XML et un élément racine grammar, comme défini dans le chapitre 4.3.
La spécification des grammaires de forme XML et ces critères de conformité n'imposent aucune limite de taille sur un aspect quelconque du document de grammaire. Il n'y a pas de valeur maximale associée au nombre d'éléments, au volume de données textuelles ou au nombre de caractères d'une valeur d'attribut.
On peut utiliser l'espace de nommage de la grammaire en même temps que d'autres espaces de nommage XML conformément à la recommandation des espaces de nommage XML [XMLNS]. Des travaux futurs du W3C indiqueront comment établir la conformité des documents impliquant plusieurs espaces de nommage.
Un processeur grammatical de forme XML est un programme capable d'analyser et de traiter des documents de grammaire de forme XML. Les logiciels de reconnaissance vocale et les détecteurs DTMF acceptant la forme XML en sont des exemples.
Dans un processeur grammatical de forme XML conforme, l'analyseur XML doit être capable d'analyser et de traiter toutes les structures XML définies par la spécification XML 1.0 [XML] et par la spécification des espaces de nommage XML [XMLNS]. Cet analyseur XML n'est pas tenu de valider le document de grammaire contre son schéma ou sa définition DTD. Cela implique que pendant le traitement d'un document de grammaire de forme XML l'application ou le développement des appels d'entités définies dans une définition DTD externe sont optionnels.
Un processeur grammatical de forme XML conforme doit reconnaître et appliquer correctement la sémantique de chaque caractéristique de grammaire possible définie par le présent document.
Un processeur grammatical de forme XML conforme doit satisfaire aux conditions de manipulation de langues suivantes :
Le processeur grammatical conforme est tenu de réussir à analyser toutes les déclarations de langue légales ;
Le processeur grammatical conforme devrait informer son environnement hôte lorsqu'il rencontre une langue non prise en charge ;
Le processeur grammatical conforme annonçant la prise en charge d'une langue donnée doit être capable d'activer la racine, toute règle publique seule, ou tout ensemble de règles publiques ou de racines d'une ou de plusieurs grammaires, où se trouvent chaque règle ou racine et toutes les sous-règles appelées directement ou indirectement pour la langue en question ;
Le processeur grammatical conforme peut activer une partie (c'est-à-dire, la racine, une règle publique seule ou un ensemble de règles publiques) d'une ou des grammaires où les parties contiennent plusieurs langues, avec une ou plusieurs langues dans chaque partie. Si le processeur est capable de prendre en charge chaque langue de cet ensemble mais pas de les manipuler en même temps, alors il devrait en informer l'environnement hôte. Si l'ensemble comprend une ou plusieurs langues non prises en charge par le processeur, il devrait aussi en informer l'environnement hôte ;
Un processeur grammatical conforme peut mettre en œuvre des langues par des substitutions approximatives conformément à un comportement documenté spécifique de la plate-forme. Par exemple, l'utilisation d'un logiciel de reconnaissance vocale anglo-américain pour traiter une entrée en anglais britannique.
Lorsque le processeur grammatical de forme XML conforme rencontre des éléments et attributs appartenant à un espace de nommage non grammatical, il peut :
Ignorer les éléments et/ou attributs non standards, ou ;
Traiter les éléments et/ou attributs non standards, ou ;
Rejeter le document contenant ces éléments et/ou attributs.
Un processeur grammatical de forme XML conforme n'est pas tenu de prendre en charge les grammaires récursives, c'est-à-dire des grammaires contenant des appels de règles auto-appelantes, directs ou indirectss.
Sinon aucune condition de conformité ne s'applique aux caractéristiques fonctionnelles d'un processeur grammatical de forme XML. Par exemple, il n'est pas nécessaire de déclarer la précision, la vitesse ou les autres caractéristiques d'un logiciel de reconnaissance vocale ou d'un détecteur DTMF. Aucune mention n'est faite à propos de la dimension de la grammaire ou de celle du vocabulaire de grammaire que doit gérer un processeur grammatical de forme XML.
Un document de grammaire de forme ABNF est un document ABNF conforme s'il adhère au présent document ( La spécification des grammaires de reconnaissance vocale ), y compris la spécification formelle du langage ABNF.
Un processeur grammatical de forme ABNF est un programme capable d'analyser et de traiter des documents de grammaire de forme ABNF. Les logiciels de reconnaissance vocale et les détecteurs ABNF acceptant la forme ABNF en sont des exemples.
Un processeur grammatical de forme ABNF conforme doit reconnaître et appliquer la sémantique de chaque caractéristique de grammaire possible définie par le présent document.
Un processeur grammatical de forme ABNF conforme doit obéir aux mêmes conditions de manipulation de langues que celles présentées dans le chapitre 5.4 pour les processeurs grammaticaux de forme XML conformes.
Un processeur grammatical de forme ABNF conforme devrait informer son environnement hôte lorsqu'il rencontre un document de grammaire illégal ou un autre contenu de grammaire qu'il ne peut pas traiter.
Un processeur grammatical de forme ABNF conforme n'est pas tenu de prendre en charge les grammaires récursives, c'est-à-dire des grammaires contenant des appels de règles auto-appelantes, directs ou indirectss.
Sinon aucune condition de conformité ne s'applique aux caractéristiques fonctionnelles d'un processeur grammatical de forme ABNF. Par exemple, il n'est pas nécessaire de déclarer la précision, la vitesse ou les autres caractéristiques d'un logiciel de reconnaissance vocale ou d'un détecteur DTMF. Aucune mention n'est faite à propos de la dimension de la grammaire ou de celle du vocabulaire de grammaire que doit gérer un processeur grammatical de forme ABNF.
Un processeur grammatical de forme ABNF/XML doit satisfaire à tous les critères de conformité définis dans le chapitre 5.4 et le chapitre 5.6.
En outre, le processeur grammatical de forme ABNF/XML doit être capable de résoudre et d'appliquer les appels depuis les grammaires de forme XML vers celles de forme ABNF, et inversement, depuis les grammaires de forme ABNF vers celles de forme XML.
Un agent utilisateur conforme est un processeur grammatical de forme XML conforme, un processeur grammatical de forme ABNF conforme, ou un processeur grammatical de forme ABNF/XML conforme, capable de recevoir une entrée d'utilisateur dans le mode de la grammaire (c'est-à-dire une entrée vocale en mode "voice", une entrée DTMF en mode "dtmf"), et capable de :
Déterminer si la séquence d'entrée d'utilisateur correspond exactement à une grammaire, et ;
Produire une représentation en sortie indiquant comment l'entrée correspond à la grammaire.
La technologie de reconnaissance vocale actuelle s'appuie sur des méthodes statistiques. Puisque la sortie n'est pas déterministe et qu'aucune représentation correcte de l'entrée n'est garantie, il n'y a aucune condition de conformité pour la précision. Toutefois, un test de conformité peut nécessiter des exemples de reconnaissance correcte d'entrée vocale pour déterminer la conformité.
Ce document a été écrit avec la participation des membres du groupe de travail Voice Browser du W3C (liste dans l'ordre alphabétique) :
Jerry Carter, expert invité
Debbie Dahl, expert invité
Les mots-clés à employer dans les RFC pour indiquer les niveaux d'obligation , S. Bradner. IETF RFC 2119. Cf. http://www.ietf.org/rfc/rfc2119.txt
Les extensions de courrier Internet multiusages (MIME) tome 1 : Le format du corps des messages Internet , N. Freed et N. Borenstein. IETF RFC 2045. Novembre 1996. Cf. http://www.ietf.org/rfc/rfc2045.txt
Les extensions de courrier Internet multiusages (MIME) tome 2 : Les types de médias , N. Freed et N. Borenstein. IETF RFC 2046. Novembre 1996. Cf. http://www.ietf.org/rfc/rfc2046.txt
Les identificateurs de ressource uniformes (URI) : La syntaxe générique , T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter. IETF RFC 2396. 1998. Cf. http://www.ietf.org/rfc/rfc2396.txt
XML Schema tome 1 : Les structures , H. S. Thompson, et al. Recommandation du W3C, mai 2001. Cf. http://www.w3.org/TR/xmlschema-1/
XML Schema tome 2 : Les types de données , P.V. Biron, A. Malhotra. Recommandation du W3C, mai 2001. Cf. http://www.w3.org/TR/xmlschema-2/
La liste des types de médias (types MIME) enregistrés auprès de l'IANA . Cf. http://www.iana.org/assignments/media-types/index.html
Le langage de balisage extensible (XML) 1.0 (deuxième édition) , World Wide Web Consortium. Recommandation du W3C, 6 octobre 2000. Cf. http://www.w3.org/TR/2000/REC-xml-20001006
XML Base , J. Marsh, rédacteur. Recommandation du W3C, juin 2001. Cf. http://www.w3.org/TR/2001/REC-xmlbase-20010627/
Les espaces de nommage dans XML , World Wide Web Consortium. Recommandation du W3C. Cf. http://www.w3.org/TR/REC-xml-names/
Le modèle de caractères du Web 1.0 , World Wide Web Consortium. Version préliminaire du W3C, 20 décembre 2001. Cf. http://www.w3.org/TR/charmod/
L'initiative de métadonnées Dublin Core , Cf. http://dublincore.org/.
The Java Language Specification (First Edition) , James Gosling, Bill Joy et Guy Steele. Addison-Wesley. Cf. http://java.sun.com/docs/books/jls/
JSpeech Grammar Format , Sun Microsystems. Soumission au W3C par la société Sun Microsystems. Cf. http://www.w3.org/TR/jsgf/
La spécification HTML 4.01 , World Wide Web Consortium. Recommandation du W3C, 24 décembre 1999. Cf. http://www.w3.org/TR/1999/REC-html401-19991224/
ISO/IEC 10646-1993 (E). Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane , ISO (International Organization for Standardization). [Geneva]: International Organization for Standardization, 1993 (plus les amendements AM 1 à AM 7).
La spécification des modèles de langue stochastiques (N-Gram) , World Wide Web Consortium. Version préliminaire du W3C. Cf. http://www.w3.org/TR/ngram-spec/
Le langage de balisage sémantique des langues naturelles. , World Wide Web Consortium. Version préliminaire du W3C, 20 novembre 2000. Cf. http://www.w3.org/TR/nl-spec/
Les conditions requises pour le balisage des lexiques de prononciations , World Wide Web Consortium. Version préliminaire du W3C, 12 mars 2001. Cf. http://www.w3.org/TR/lexicon-reqs/
Multifrequency push-button signal reception , International Telecommunication Union. Recommandation ITU approuvée 1988-11. Cf. http://www.itu.int/home/index.html
La spécification du modèle et de la syntaxe du cadre de description de ressources (RDF) , Ora Lassila et Ralph R. Swick. Recommandation du W3C, 22 février 1999. Cf. http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
La spécification du schéma du cadre de description de ressources (RDF) 1.0 , Dan Brickley et R.V. Guha. Recommandation candidate du W3C, mars 2000. Cf. http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
Les étiquettes d'identification des langues , H. Alvestrand. IETF RFC 1766. Cf. http://www.ietf.org/rfc/rfc1766.txt
Le protocole de transfert hypertexte — HTTP/1.1 , R. Fielding, et al. IETF RFC 2616. 1999. Cf. http://www.ietf.org/rfc/rfc2616.txt
Le format des adresses IPv6 littérales dans les adresses URL , R. Hinden, B. Carpenter, L. Masinter. IETF RFC 2732. 1999. Cf. http://www.ietf.org/rfc/rfc2732.txt
Les étiquettes d'identification des langues , H. Alvestrand. IETF RFC 3066. Cf. http://www.ietf.org/rfc/rfc3066.txt
L'interprétation sémantique de la reconnaissance vocale , World Wide Web Consortium. Version préliminaire du W3C, 16 novembre 2001. Cf. http://www.w3.org/TR/semantic-interpretation/
Introduction à TalkML , Dave Raggett. Note du W3C. Cf. http://www.w3.org/Voice/TalkML/
Le langage de balisage extensible vocal (VoiceXML) version 1.0 , VoiceXML Forum. Note du W3C, 5 mai 2000. Voir http://www.w3.org/TR/2000/NOTE-voicexml-20000505/
Le langage de balisage extensible vocal (VoiceXML) version 2.0 , World Wide Web Consortium. Version préliminaire du W3C, 23 octobre 2001. Cf. http://www.w3.org/TR/2001/WD-voicexml20-20011023/
Annexe B : La définition DTD des grammaires de forme XML
La définition DTD se trouve à http://www.w3.org/TR/speech-grammar/grammar.dtd
Annexe C : La définition XML Schema des grammaires de forme XML
Le schéma des grammaires se trouve à http://www.w3.org/TR/speech-grammar/grammar.xsd
Remarque : Le schéma des grammaires contient le schéma de base sans espace de nommage (cf. ci-dessous).
Le schéma de base sans espace de nommage des grammaires se trouve à http://www.w3.org/TR/speech-grammar/grammar-core.xsd. Il peut servir de base pour définir des fragments de grammaire de forme XML incorporés aux schémas d'espaces de nommage non grammaticaux.
Annexe D : La syntaxe formelle des grammaires de forme ABNF
On emploie ici la notation EBNF (N.d.T. Extended Backus-Naur Form) définie dans la recommandation XML 1.0 [XML §6].
La gestion des caractères blancs de la forme ABNF suit la gestion des caractères blancs et des fins de ligne du langage XML (cf. le chapitre 1.6).
La grammaire lexicale de ABNF
La grammaire lexicale définit les atomes lexicaux du format ABNF et elle a des caractères seuls comme symboles terminaux. En conséquence, ni les caractères blancs ni les commentaires ABNF ne sont admis dans les atomes lexicaux, sauf indication contraire explicite.
SelfIdentHeader     ::=
[Contraintes supplémentaires :
- Un caractère fin de ligne doit immédiatement
suivre le caractère point-virgule ; .
VersionNumber       ::=
CharEncoding        ::=
BaseURI             ::=
LanguageCode        ::=
- Le code de langue doit être un identificateur de langue valide.
RuleName            ::=
ConstrainedName     ::=
TagFormat           ::=
LexiconURI          ::=
SingleQuotedCharacters  ::=
DoubleQuotedCharacters  ::=
QuotedCharacters    ::=
Weight              ::=
Repeat              ::=
- Le nombre à droite du tiret ne doit pas être
supérieur au nombre à gauche du tiret.
Probability         ::=
- La valeur flottante doit se trouver dans l'intervalle
de "0.0" à "1.0" (inclus).
Number              ::=
ExternalRuleRef     ::=
- La grammaire appelée doit avoir le même mode
("voice" ou "dtmf") que la grammaire appelante.
- Si l'appel d'adresse URI contient un identificateur
de fragment, la règle appelée doit être une
règle publique d'une autre grammaire.
- Si l'appel d'adresse URI ne contient pas
d'identificateur de fragment, c-à-d. si c'est un
appel de règle racine implicite, alors la
grammaire appelée doit déclarer une règle racine.
Token               ::=
LanguageAttachment  ::=
Tag                 ::=
Les types ABNF_URI et ABNF_URI_with_media_type
sont définis dans le chapitre 1.6 La terminologie.
Le type Name est défini par la production Name de XML [XML §2.3].
Le type Nmtoken est défini par la production Nmtoken de XML [XML §2.3].
Le type NameChar est défini par la production NameChar de XML [XML §2.3].
Le type Char est défini par la production Char de XML [XML §2.2].
Remarque : Comme indiqué dans le chapitre 2.5, les symboles étoile * , plus + et point d'interrogation ? , souvent utilisés dans les langages d'expressions rationnelles, sont réservés pour un usage futur dans ABNF. On ne doit pas les utiliser dans une grammaire là où la syntaxe actuelle autorise la présence d'un opérateur de répétition.
La grammaire syntaxique du langage ABNF
La grammaire syntaxique possède des atomes lexicaux que la grammaire lexicale définit comme symboles terminaux. Un nombre quelconque de caractères blancs ou de commentaires ABNF peuvent apparaître entre deux atomes lexicaux.
grammaire           ::=
declaration         ::=
baseDecl            ::=
- Une déclaration de base ne doit pas apparaître
plus d'une fois dans une grammaire.
languageDecl        ::=
- Une déclaration de langue ne doit pas apparaître
- La déclaration de langue est obligatoire si
la grammaire a le mode "voice".
modeDecl            ::=
- Une déclaration de mode ne doit pas apparaître
rootRuleDecl        ::=
- Une déclaration de règle racine ne doit pas apparaître
- La règle racine doit être définie
dans la grammaire.
tagFormatDecl       ::=
- Une déclaration de format de balise ne doit pas apparaître
lexiconDecl         ::=
metaDecl            ::=
tagDecl             ::=
ruleDefinition      ::=
- Le nom d'une règle doit être unique au sein d'une grammaire,
c-à-d., aucune règle ne doit y être définie plus d'une fois.
scope               ::=
ruleExpansion       ::=
ruleAlternative     ::=
sequenceElement     ::=
subexpansion        ::=
ruleRef             ::=
localRuleRef        ::=
- La règle appelée doit être définie au sein
de la même grammaire.
specialRuleRef      ::=
repeatOperator      ::=
Annexe E : Les grammaires DTMF
Ce chapitre définit la représentation normative d'une grammaire composée d'atomes DTMF. Une grammaire DTMF peut être utilisée par un détecteur DTMF pour déterminer des séquences d'événements DTMF légaux ou illégaux. Tous les processeurs grammaticaux acceptant les grammaires de mode dtmf doivent mettre en œuvre cette annexe. Par contre, les processeurs grammaticaux ne sont pas tous obligés de reconnaître les entrées DTMF.
Si le mode de la grammaire est déclaré de type dtmf , alors les atomes qu'elle contient sont traités comme des tonalités DTMF (et non comme des atomes vocaux par défaut).
Il existe seize (16) tonalités DTMF. Sur ce nombre, douze (12) se trouvent couramment sur les combinés téléphoniques, les chiffres de "0" à "9" plus les symboles étoile * et dièse # . Les quatre tonalités DTMF A , B , C et D sont habituellement absentes des combinés.
Chaque symbole DTMF est un atome DTMF légal dans une grammaire DTMF. Comme pour les grammaires vocales, les atomes d'une grammaire DTMF doivent être séparés par des caractères blancs. Une séquence de symboles DTMF, séparés par des caractères espace, représente une séquence temporelle d'éléments DTMF.
Dans la forme ABNF, le symbole étoile * est réservé, et il faut toujours utiliser des guillemets doubles pour le délimiter dans une définition de grammaire DTMF de forme ABNF. On recommande également de placer le symbole dièse # entre guillemets. Sinon les atomes étoile et dièse font des synonymes acceptables.
Quelle que soit la grammaire DTMF, toute déclaration de langue dans l'en-tête de la grammaire est ignorée, de même que toutes les associations de langue sur les extensions de règles.
Pour tous les autres aspects, une grammaire DTMF suit la même syntaxe que celle d'une grammaire vocale. Par exemple, les grammaires DTMF peuvent utiliser les appels de règles, les règles spéciales, les balises et les autres caractéristiques de spécification.
Voici une grammaire DTMF simple acceptant un numéro d'identification personnel (PIN) de quatre chiffres suivi d'un terminateur dièse. Elle accepte également la séquence constituée d'une étoile * suivie du chiffre "9" (par exemple, pour obtenir un message d'aide).
Annexe F : Une feuille de style XSLT pour convertir les grammaires de forme XML en ABNF
La transformation proposée ici illustre la conversion d'une grammaire de forme XML en une forme ABNF. Les limitations connues sont les suivantes :
Les commentaires ne sont pas transformés ;
Aucun traitement d'éléments atomiques vides (illégaux dans la forme ABNF) ;
Les noms de fichiers (par exemple, grammaire.grxml ) et les types de médias ( application/srgs+xml ) sont préservés dans les adresses URI et les déclarations de type de média ;
Le contenu entre guillemets des attributs meta est supposé entre guillemets doubles. Mauvais conversion des attributs meta contenant des guillemets simples.
Le document source de cette transformation se trouve à http://www.w3.org/TR/speech-grammar/grammar-transformer.xsl.
Annexe G : Les types de médias et les suffixes de fichiers
Le groupe de travail Voice Browser du W3C a demandé auprès de l'IANA l'enregistrement de deux types de médias pour la spécification des grammaires de reconnaissance vocale, l'un pour la forme ABNF et l'autre pour la forme XML.
Le type de média ABNF identifie les grammaires de forme ABNF. Le type de média demandé est application/srgs .
De même, le type de média d'une grammaire de forme XML identifie les grammaires de forme XML. Le type de média demandé est application/srgs+xml .
Le groupe de travail Voice Browser du W3C a adopté les conventions d'utilisation suivantes : le suffixe de nom de fichier .gram pour les documents de grammaire de forme ABNF, et le suffixe de nom de fichier .grxml pour les documents de grammaire de forme XML.
Annexe H : La structure d'analyse logique
Ce chapitre définit une représentation informative du résultat de reconnaissance vocale analysé, ou du traitement par un autre agent utiliseur. Cette représentation peut servir de base à un traitement consécutif de l'entrée d'utilisateur, notamment une interprétation sémantique. Par exemple, la spécification L'interprétation sémantique de la reconnaissance vocale du W3C [SEM] est définie autour de la structure d'analyse logique.
Cette annexe reprend la terminologie et la nomenclature trouvés dans le livre Introduction to Automata Theory, Languages, and Computation [HU79].
On représente les atomes composant l'alphabet de tous les atomes acceptés par une grammaire par a1, a2, etc.
Une séquence d'atomes en entrée ou en sortie est une chaîne d'atomes séparés par des caractères espaces. La structure d'analyse logique contient des atomes avec des caractères blancs normalisés. Les atomes dans la structure d'analyse logique sont délimités en option par des guillemets doubles, de façon à pouvoir analyser les caractères blancs et d'autres caractères sans ambiguïté, par exemple, a1, a2, "a3 avec espaces" . (Pour la cohérence, tous les exemples de cette annexe adoptent des guillemets doubles).
Soit les atomes ε (epsilon) ou "" , représentant la chaîne unique de longueur nulle appelée également la chaîne vide.
On représente les balises appartenant à l'ensemble de toutes les balises acceptées par une grammaire par {bal1}, {bal2}, ... .
On représente une extension légale par E . (Les extensions légales sont définies dans le chapitre 2).
La capacité d'expression d'une extension de règle est une expression rationnelle (N.d.T. Regular Expression) et elle équivaut à une machine finie (N.d.T. Finite Automaton), cf. [HU79]. (La manipulation des appels de règles nécessite un traitement spécial, cf. l'annexe H.2). La capacité d'expression de la spécification de grammaire est constituée par des :
Atomes : une transition de machine finie avec un symbole
Balises : une transition de machine finie sur l'ensemble vide ε
Séquences : une opération de concaténation sur une machine finie
Choix : une opération d'union sur une machine finie
Répétitions : représentables par des combinaisons de concaténations, clotûres et unions.
Nous formalisons la structure d'analyse logique en créant une machine finie avec sortie (N.d.T. Finite Automaton with Output), cf. [HU79]. Cette structure est également appelée un transducteur à états finis (N.d.T. Finite State Transducer)
Nous définissons les transitions des atomes et des balises comme produisant un symbole de sortie.
Atome : une transition recevant l'atome a et produisant l'atome de sortie a .
Selon la notation de HU79 : a/a
Balise : une transition recevant ε (aucun atome) et produisant {!{bal}!}
Selon la notation de HU79 : ε/{!{bal}!}
Nous représentons la sortie d'analyse par un tableau ordonné d'entités de sortie : [e1,e2,e3,...] .
Une entité e peut être un atome, une balise ou une extension de règle (cf. l'annexe H.2).
Un tableau de sortie vide est représenté par [ε] ou plus simplement par [] .
Un appel $NULL équivaut à une transition acceptant en entrée ε et produisant en sortie ε . Selon la notation de HU79 : ε/ε .
Un appel $VOID équivaut logiquement à une transition manquante. Elle n'accepte pas d'entrée et ne produit pas de sortie.
Un appel $GARBAGE équivaut à une transition acceptant une entrée spécifique à une plateforme et produisant en sortie ε .
Une ambiguïté apparaît si, en comparant une séquence définie d'atomes en entrée à une règle de grammaire donnée, plusieurs structures d'analyse logique distinctes peuvent être produites.
Une ambiguïté peut se produire aux points de disjonction (choix) de la grammaire. Les disjonctions naissent à l'utilisation de choix et de répétitions.
Le processeur grammatical peut conserver plusieurs structures d'analyse logique ambiguës pour créer un ensemble de choix de structures d'analyse logique pour l'entrée. Il peut légalement maintenir toutes les structures d'analyse logique possibles, ou ne retenir qu'un choix et se débarasser des autres. Il n'est défini aucun comportement du processeur grammatical en ce qui concerne la sélection d'un choix parmi les ambiguïtés possibles. Par conséquent, les grammaires contenant des ambiguïtés ne présentent aucune garantie de portabilité du fonctionnement. Les développeurs et les outils grammaticaux devraient tenir compte des ambiguïtés.
Cette annexe ne constitue pas un catalogue de toutes les formes d'extensions ambiguës mais elle en fournit quelques exemples courants.
Le filtrage d'un atome à un atome produit un tableau d'un seul atome.
Sortie ["a1"]
Un appel $NULL est filtré par une séquence d'entrée vide et la sortie est un tableau vide.
Extension $NULL
Entrée ""
Sortie []
Une balise est filtrée par une séquence d'entrée vide et la sortie est un tableau d'une seule balise.
Extension {bal} ou {!{bal}!}
Sortie [{!{bal}!}]
Concaténation : une extension composée d'un atome et d'une balise est filtrée par une entrée contenant l'atome, elle produit en sortie un tableau d'un atome et d'une balise.
Extension a1 {bal1}
Sortie ["a1",{!{bal1}!}]
Concaténation : une extension composée d'une séquence d'atomes, de balises et de règles $NULL est filtrée par une entrée constituée des atomes contenus. La sortie se compose de la séquence des atomes et des balises dans le même ordre.
Extension a1 $NULL {bal1} a2 {bal2} a3
Entrée a1 a2 a3
Sortie ["a1",{!{bal1}!},"a2",{!{bal2}!},"a3"]
Les structures entre parenthèses ne se traduisent pas dans le résultat. L'exemple suivant est identique au précédent hormis l'ajout de parenthèses à la définition d'extension.
Extension ((a1) $NULL) {bal1} (a2 {bal2} a3)
Choix : un ensemble de plusieurs choix d'atomes est filtré par l'entrée d'un seul atome et elle produit un seul atome en sortie.
Extension a1 | a2 |a3
Sortie ["a2"]
Choix : si une extension seule dans un ensemble de choix peut être filtrée par une entrée nulle, alors l'ensemble de choix peut être filtré par une entrée nulle, et la sortie est celle d'une extension acceptant une valeur nulle. (La règle $NULL, les balises {bal} et les répétitions de compte zéro permettent toutes une entrée nulle).
Extension a1 | a2 | $NULL
Autre exemple avec une extension acceptant une valeur nulle :
Extension a1 | a2 | {bal}
Choix et ambiguïté : plusieurs exemples d'extensions ambiguës, l'ambiguïté provenant de choix acceptant la même entrée mais produisant une sortie différente.
Extension a1 {bal1} | a1 {bal2} | a2
Sortie 1 ["a1",{!{bal1}!}]
Sortie 2 ["a1",{!{bal2}!}]
Dans cet exemple, l'entrée nulle est ambiguë.
Extension {bal1} | {bal2} | $NULL
Sortie 1 [{!{bal1}!}]
Sortie 2 [{!{bal2}!}]
Sortie 3 []
Il n'y a aucune ambiguïté dans ce qui suit car les différents chemins à travers l'extension produisent la même sortie.
Extension a1 | a1 | a2
Sortie 1 ["a1"]
Sortie 2 ["a1"]
Répétitions : une extension optionnelle peut être filtrée soit par une séquence atomique vide, soit par toute séquence d'atomes correspondant à l'extension optionnelle.
Extension a1 <0-1>
Entrée 1 ""
Sortie 1 []
Entrée 2 a1
Répétitions : l'ordre est conservé sur plusieurs extensions.
Extension (a1 {bal1}) <0-3>
Sortie 2 ["a1",{!{bal1}!}]
Entrée 3 a1,a1,a1
Sortie 3 ["a1",{!{bal1}!},"a1",{!{bal1}!},"a1",{!{bal1}!}]
Répétitions et entrée nulle : si le contenu d'une extension optionnelle peut être filtré par une séquence d'entrée vide ET que la sortie issue du filtrage de l'extension contenue est toujours un tableau vide, alors la sortie issue du filtrage de l'extension optionnelle par une séquence vide est toujours un tableau vide.
Extension $NULL <0-1>
Répétitions ambiguës : si une extension répétée ou optionnelle peut être filtrée par une séquence d'entrée vide MAIS que la sortie issue du filtrage de l'extension contenue peut contenir des balises, alors l'analyse est ambiguë. On recommande une analyse minimale : la sortie 1 est préférable.
Extension {bal} <0->
Sortie 2 [{!{bal}!}]
Sortie 3 [{!{bal}!},{!{bal}!}]
Sortie N [{!{bal}!},{!{bal}!},{!{bal}!},...]
Une ambiguïté similaire apparaît si l'extension répétée contient une extension de remplacement dont l'extension accepte une valeur nulle.
Extension (a1 | {bal}) <0-3>
Sortie 2 ["a1",{!{bal}!}]
Sortie 3 [{!{bal}!},"a1"]
Sortie 4 ["a1",{!{bal}!},{!{bal}!}]
Sortie 5 [{!{bal}!},"a1",{!{bal}!}]
Sortie 6 [{!{bal}!},{!{bal}!},"a1"]
Une séquence de deux extensions avec répétition peut se révéler ambiguë si les deux extensions répétées peuvent accepter la même entrée mais produire une sortie différente.
Extension (a1 {bal1}) <0-2> (a1 {bal2}) <0-2>
Entrée a1,a1,a1
Sortie 1 ["a1",{!{bal1}!},"a1",{!{bal1}!},"a1",{!{bal1}!}
Sortie 2 ["a1",{!{bal1}!},"a1",{!{bal1}!},"a1",{!{bal2}!}
Sortie 3 ["a1",{!{bal1}!},"a1",{!{bal2}!},"a1",{!{bal2}!}
Sortie 4 ["a1",{!{bal2}!},"a1",{!{bal2}!},"a1",{!{bal2}!}
Un appel de règle est une extension de règle légale (voir le chapitre 2.2).
La sortie issue du filtrage de la séquence d'atomes "a1,a2,..." par l'extension $nom-de-regle est notée par $nom-de-regle[e1,e2,...] , où "e1,e2,..." est la séquence d'entités issue du filtrage de cette séquence d'atomes par l'extension de règle définie pour $nom-de-regle . Lorsque nous appelons une règle externe, nous utilisons la syntaxe d'appel de règle ABNF (sans type de média). Par exemple, $<http://www.example.com/grammaire.grxml#nom-de-regle">[e1,e2,...] , ou un appel de règle racine implicite $<http://www.example.com/grammaire.grxml">[e1,e2,...] . Pour la concision, tous les exemples suivants utilisent seulement des appels de règles locales.
Le nom de règle de la règle de premier niveau devrait englober la structure d'analyse logique.
Une structure distincte du filtrage des appels de règles conserve l'arbre d'analyse du résultat. On peut utiliser cette structure pour le processus d'interprétation sémantique ou les autres processus de calcul qui découlent de la structure de l'analyse de sortie.
Il n'y a pas de distinction entre les appels de règles locales (dans la même grammaire) et les appels de règles externes.
Il n'y a pas de distinction entre l'appel d'une règle racine et l'appel d'une grammaire nommée.
Voici un exemple d'appel de règle simple.
Règle $x = a1 a2 a3;
Extension $x
Entrée a1,a2,a3
Sortie $x["a1","a2","a3"]
Voici un appel de règle dans une séquence.
Règle $x = a2 a3 a4;
Extension a1 $x a5
Entrée a1,a2,a3,a4,a5
Sortie ["a1",$x["a2","a3","a4"],"a5"]
Cet exemple inclut un appel de règle produisant une balise en sortie.
Règle $x = a2 {bal};
Extension a1 $x a3
Sortie ["a1",$x["a2",{!{bal}!}],"a3"]
Plusieurs appels de la même règle sont permis.
Règle $x = a1 {bal1};
Extension $x $x $x
Sortie [$x["a1",{!{bal1}!}],$x["a1",{!{bal1}!}],$x["a1",{!{bal1}!}]]
Les appels de règles peuvent se répéter.
Règle $x = a1 {bal};
Extension $x <0->
La spécification des grammaires de reconnaissance vocale possède la capacité d'expression d'une grammaire indépendante du contexte. Cela provient du fait que le langage permet l'auto-appel d'une règle directement ou indirectement. [Remarque : Un processeur grammatical de forme XML conforme ou un processeur grammatical de forme ABNF conforme ne sont pas obligés de prendre en compte les grammaires récursives.]
Il n'y a pas de représentation distincte des appels de règles récursifs.
Récursion à droite simple. Remarque : Cette grammaire peut s'écrire dans une forme non récursive (expression rationnelle).
Règle $x = a1 {dernier} | a1 $x;
Sortie [$x["a1",$x["a1",$x["a1",{!{dernier}!}]]]]
Récursion incorporée. Remarquez que cet exemple filtre toute séquence de n atomes a1 suivie de n atomes a2 .
Règle $x = {fond} | (a1 $x a2);
Entrée a1,a1,a2,a2
Sortie [$x["a1",$x["a1",$x[{!{fond}!}],"a2"],"a2"]]
Annexe I : Les fonctionnalités à l'étude pour les versions futures
Les fonctionnalités suivantes sont à l'étude pour les versions à suivre de la spécification des grammaires de reconnaissance vocale 1.0 :
Des optimisations des grammaires dynamiques : par exemple, les mots-clés static ou volatile sur les définitions de règles ;
Une variation dynamique des poids sur les choix ;
Une définition des fragments de grammaire ;
Une manipulation explicite des variantes morphologiques des atomes ;
Une définition incorporée de la prononciation d'un atome ;
Un guidage des logiciels de reconnaissance sur les modèles acoustiques ;
Une gestion du lexique de prononciaton du W3C quand il sera prêt ;
Une déclaration des types de retour sémantiques des règles ;
Une éventuelle distinction entre les règles de type activable et celles de type exported (règles actuellement réunies sous le type public ) ;
Des grammaires multimodes : par exemple, voix et DTMF mélangés, voix et clavier, voix et pointeur, etc. ;
Des critères de conformité pour les générateurs de grammaires ;
Une gestion des paramètres de délai d'attente au sein des grammaires (par exemple, un délai entre chiffres d'une grammaire DTMF) ;
Une gestion des tonalités DTMF longues (par exemple, accepter une tonalité de 1000ms ou plus) ;
Une utilisation du langage XLink pour les appels d'adresses URI.
Appendix J : Exemples de grammaires de forme ABNF et de forme XML
J.1 : Exemples simples (en français)
Voici une grammaire simple reconnaissant des commandes telles que ouvrir un fichier et veuillez déplacer la fenêtre . Elle appelle une grammaire de formules de politesse définie séparément et non visible ici.
root $commandesDeBase;
* Commandes de base.
* @example veuillez déplacer la fenêtre
* @example ouvrir un fichier
public $commandesDeBase =
$<http://grammar.example.com/politesse.gram#debutPolitesse>
$<http://grammar.example.com/politesse.gram#finPolitesse>;
$action = /10/ ouvrir {CONTENU-DE-BALISE-1} | /2/ fermer {CONTENU-DE-BALISE-2}
| /1/ supprimer {CONTENU-DE-BALISE-3} | /1/ déplacer {CONTENU-DE-BALISE-4};
$objet = [le | la | un | une] (fenêtre | fichier | menu);
<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="fr"
version="1.0" mode="voice" root="commandesDeBase">
<rule id="commandesDeBase" scope="public">
<example> veuillez déplacer la fenêtre </example>
<example> ouvrir un fichier </example>
<ruleref uri="http://grammar.example.com/politesse.grxml#debutPolitesse"/>
<ruleref uri="#commande"/>
<ruleref uri="http://grammar.example.com/politesse.grxml#finPolitesse"/>
<item weight="10"> ouvrir    <tag>CONTENU-DE-BALISE-1</tag> </item>
<item weight="2">  fermer    <tag>CONTENU-DE-BALISE-2</tag> </item>
<item weight="1">  supprimer <tag>CONTENU-DE-BALISE-3</tag> </item>
<item weight="1">  déplacer  <tag>CONTENU-DE-BALISE-4</tag> </item>
<rule id="objet">
<item> le </item>
<item> la </item>
<item> un </item>
<item> une </item>
<item> fenêtre </item>
<item> fichier </item>
J.2 : Exemples avec références croisées (en français)
Les deux grammaires suivantes illustrent un référencement mutuel de grammaires. La même grammaire est présentée dans les deux formes ABNF et XML.
Grammaire de forme ABNF : http://www.example.com/destination.gram
root $ville_etat;
public $ville = Boston | Philadelphie | Fargo;
public $etat = Floride | Dakota du Nord | New York;
// Appels de règles locales
// Un exemple artificiel permet le couple "Boston, Floride"
public $ville_etat = $ville $etat;
Grammaire de forme ABNF : http://www.example.com/enregistrement.gram
// Appel selon une syntaxe d'adresse URI
public $vol = Je veux voler vers
$<http://www.example.com/destination.gram#ville>;
public $marche = Je veux marcher vers $<http://www.example.com/destination.gram#etat>;
// Appel implicite de la règle racine par une adresse URI
public $nage = Je veux nager vers $<http://www.example.com/destination.gram>;
Grammaire de forme XML : http://www.example.com/destination.grxml
xml:lang="fr" version="1.0" root="ville_etat" mode="voice">
<rule id="ville" scope="public">
<item>Philadelphie</item>
<rule id="etat" scope="public">
<item>Floride</item>
<item>Dakota du Nord</item>
<!-- Appel par adresse URI d'une règle locale -->
<!-- Un exemple artificiel permet le couple "Boston, Floride" -->
<rule id="ville_etat" scope="public">
<ruleref uri="#ville"/> <ruleref uri="#etat"/>
Grammaire de forme XML : http://www.example.com/enregistrement.grxml
xml:lang="fr" version="1.0" mode="voice">
<!-- En utilisant une syntaxe d'adresse URI -->
<rule id="vol" scope="public">
Je veux voler vers
<ruleref uri="http://www.example.com/destination.grxml#ville"/>
<rule id="marche" scope="public">
Je veux marcher vers <ruleref uri="http://www.example.com/destination.grxml#etat"/>
<!-- Appel implicite de la règle racine d'une grammaire par une adresse URI -->
<rule id="nage" scope="public">
Je veux nager vers <ruleref uri="http://www.example.com/destination.grxml"/>
J.3 : Exemples en coréen
Les deux grammaires de forme XML suivantes ont un contenu oui/non en coréen. La première représente les symboles coréens sous forme de caractères Unicode dans un codage UTF-8. La seconde représente les mêmes caractères Unicode en utilisant un masquage des caractères.
Grammaire de forme ABNF avec des caractères Unicode dans un codage UTF-8
root $oui_non_ko;
* Grammaire oui/non coréenne simple
public $oui_non_ko = 예 | 아니오 ;
Grammaire de forme XML avec des caractères Unicode dans un codage UTF-8
root="oui_non_ko">
<!-- Grammaire oui/non -->
<rule id="oui_non_ko" scope="public">
Grammaire de forme XML avec masquage des caractères Unicode
root="principal">
J.4 : Exemples en chinois
Les deux grammaires de forme XML suivantes contiennent des nombres chinois. La première représente les symboles chinois sous forme de caractères Unicode avec un codage UTF-8. La seconde représente les mêmes caractères Unicode en utilisant un masquage des caractères.
root $principal;
public $principal = $chiffres_1_9;
private $chiffres_1_9 = 一 | 二 | 三 | 四 | 五 | 六 | 七 | 八 | 九;
xml:lang="zh" mode="voice" root="principal">
<rule id="principal" scope="public">
<ruleref uri="#chiffres_1_9"/>
<rule id="chiffres_1_9" scope="private">
J.5 : Exemples en suédois
Cette grammaire de forme XML en suédois offre un ensemble complet de formes oui et non . Tous les caractères sont contenus dans le jeu de caractères ISO-8859-1 (Latin-1).
Grammaire de forme XML dans un codage ISO-8859-1
xml:lang="sv" mode="voice" root="principal">
<ruleref uri="#regle_oui"/>
<ruleref uri="#regle_non"/>
<rule id="regle_oui" scope="private">
<ruleref uri="#emphase_oui"/>
<rule id="emphase_oui" scope="private">
<rule id="regle_non" scope="private">
<ruleref uri="#emphase_non"/>
<rule id="emphase_non" scope="private">

References: §3
 §2
 §3
 §2
 §2
 §2
 §4
 §2
 §2
 §2
 §18
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §4
 §2
 §4
 §4
 §2
 §2
 §6
 §2
 §2
 §2
 §2