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.
1. Introduction
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
<
et >
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.
Termes des conditions- 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.
Identificateur de ressource uniforme (URI)- 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.
Type de média- 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.
Identificateur de langue- 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.
Caractères blancs- 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].
DTMF- 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
.
"San Francisco"
" San Francisco "
"San
Francisco"
" San Francisco "
Puisque la présence de caractères blancs dans un atome est significative, les atomes suivants sont distincts :
"San Francisco"
"SanFrancisco"
"San_Francisco"
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.
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.
Informatif
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.
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.
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
$VOID
$GARBAGE |
<ruleref special="NULL"/>
<ruleref special="VOID"/>
<ruleref special="GARBAGE"/> |
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.
La forme ABNF
L'appel de nom de règle simple est préfixé par un caractère dollar $
.
$ville
$chiffre
La forme XML
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 :
|
|
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.
La forme ABNF
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
$<http://grammar.example.com/world-cities.gram#canada>
$<http://grammar.example.com/numbers.gram#digit>
// Appel implicite de la règle racine d'une grammaire externe
$<../date.gram>
// Appels avec type de média associé
$<http://grammar.example.com/world-cities.gram#canada>~<application/srgs>
$<../date.gram>~<application/srgs>
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.
La forme XML
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/world-cities.grxml#canada"/>
<ruleref uri="http://grammar.example.com/numbers.grxml#chiffre"/>
<!-- Appel implicite de la règle racine d'une grammaire externe -->
<ruleref uri="../date.grxml"/>
<!-- Appels avec un type de média associé -->
<ruleref uri="http://grammar.example.com/world-cities.grxml#canada"
type="application/srgs+xml"/>
<ruleref uri="../date.grxml" type="application/srgs+xml"/>
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.
NULL- 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"/>
VOID- 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"/>
GARBAGE- 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
.
$location = $city $GARBAGE $state;
<rule id="location">
<ruleref uri="#city"/>
<ruleref special="GARBAGE"/>
<ruleref uri="#state"/>
</rule>
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.
La forme ABNF
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.
$<http://grammar.example.com/ngram.xml#StartSymbol>
$<http://grammar.example.com/ngram.xml>
La forme XML
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.
<ruleref uri="http://grammar.example.com/ngram.xml#StartSymbol"/>
<ruleref uri="http://grammar.example.com/ngram.xml"/>
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).
La forme ABNF
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
Cas particuliers
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
telephone ( ) maison
La forme XML
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 -->
voici un essai
<!-- 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>
Cas particuliers
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 maison
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.
La forme ABNF
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
(1 | 2 | 3)
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
Cas particuliers
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.
// Légal
$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.
// Légal
$regle1 = /2/ mot;
$regle2 = /2/ {CONTENU-DE-BALISE};
$regle3 = /2/ $NULL;
La forme XML
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.
<one-of>
<item>Michael</item>
<item>Yuriko</item>
<item>Mary</item>
<item>Duke</item>
<item><ruleref uri="#autresNoms"/></item>
</one-of>
<one-of><item>1</item> <item>2</item> <item>3</item></one-of>
<one-of>
<item weight="10">petit</item>
<item weight="2">moyen</item>
<item>grand</item>
</one-of>
<one-of>
<item weight="3.1415">tarte</item>
<item weight="1.414">limonade</item>
<item weight=".25">soda</item>
</one-of>
Cas particuliers
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 :
<one-of>
<item>mot</item>
</one-of>
<one-of>
<item weight="2.0">mot</item>
</one-of>
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.
<one-of>
<item>mot</item>
<item/>
</one-of>
<one-of>
<item>mot</item>
<item> <ruleref special="NULL"/> </item>
</one-of>
<one-of>
<item>mot</item>
<item> <tag>CONTENU-DE-BALISE</tag> </item>
</one-of>
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 |
<n>
<6> |
repeat="n"
repeat="6" |
L'extension contenue se répète exactement n fois ; n doit être un entier positif ou nul. |
<m-n>
<4-6> |
repeat="m-n"
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. |
<m->
<3-> |
repeat="m-"
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. |
<0-1>
[...] |
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é.
Cas particuliers
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].
La forme ABNF
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
// "pizza"
// "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/>
La forme XML
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 -->
<!-- "pizza" -->
<!-- "grande pizza au poivron" -->
<!-- "très grande pizza au fromage et au poivron" -->
<item repeat="0-1">
<item repeat="0-1"> très </item>
grande
</item>
pizza
<item repeat="0-">
<item repeat="0-1">
<one-of>
<item>au</item>
<item>et</item>
</one-of>
</item>
<ruleref uri="#garniture"/>
</item>
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 %. -->
<item repeat="2-4" repeat-prob=".8">
<ruleref uri="#chiffre"/>
</item>
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.
Cas particuliers
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>
La forme ABNF
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 } }!};
La forme XML
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">
<one-of>
<item> ouvrir <tag>CONTENU-DE-BALISE-1</tag> </item>
<item> <ruleref uri="#fermer"/> <tag>CONTENU-DE-BALISE-2</tag> </item>
</one-of>
</rule>
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).
#ABNF 1.0 ISO-8859-1;
// La langue implicite de la grammaire est l'anglais américain
language en-US;
// 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é
$yes = yes | oui!fr-CA;
// Association de langue singulière à une extension
$people1 = (Michel Tremblay | André Roy)!fr-CA;
// 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
$people2 = Jose!en-US; | Jose!es-MX;
/**
* Possibles entrées multilingues
* @example may I speak to André Roy
* @example may I speak to Jose
*/
public $request = may I speak to ($people1 | $people2);
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.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
"http://www.w3.org/TR/speech-grammar/grammar.dtd">
<!-- La langue implicite de la grammaire est l'anglais américain -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/06/grammar
http://www.w3.org/TR/speech-grammar/grammar.xsd"
xml:lang="en-US" version="1.0">
<!--
Association de langue singulière à des atomes
"yes" héritage implicite de l'anglais américain
"oui" c'est le français canadien
-->
<rule id="yes">
<one-of>
<item>yes</item>
<item xml:lang="fr-CA">oui</item>
</one-of>
</rule>
<!-- Association de langue singulière à une extension -->
<rule id="people1">
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>André Roy</item>
</one-of>
</rule>
<!--
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.
-->
<rule id="people2">
<one-of>
<item xml:lang="en-US">Jose</item>
<item xml:lang="es-MX">Jose</item>
</one-of>
</rule>
<!-- Possibles entrées multilingues -->
<rule id="request" scope="public">
<example> may I speak with André Roy </example>
<example> may I speak with Jose </example>
may I speak with
<one-of>
<item> <ruleref uri="#people1"/> </item>
<item> <ruleref uri="#people2"/> </item>
</one-of>
</rule>
</grammar>
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.
La forme ABNF
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.
La forme XML
Inutile. La structure XML est explicite.
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 forme ABNF
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;
Par exemple :
$ville = Boston | "New York" | Madrid;
$commande = $action $objet;
Cas particuliers
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.
// Légal
$regle = ();
$regle = $NULL;
$regle = {CONTENU-DE-BALISE};
// ILLÉGAL
$regle = ;
La forme XML
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">
<one-of>
<item>Boston</item>
<item>"San Francisco"</item>
<item>Madrid</item>
</one-of>
</rule>
<rule id="commande">
<ruleref uri="#action"/>
<ruleref uri="#objet"/>
</rule>
Cas particuliers
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>
<rule id="regle"><tag>CONTENU-DE-BALISE</tag></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.
La forme ABNF
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;
La forme XML
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">
<one-of>
<item>Townsville</item>
<item>Beantown</item>
</one-of>
</rule>
<rule id="ville" scope="private">
<one-of>
<item>Boston</item>
<item>"San Francisco"</item>
<item>Madrid</item>
</one-of>
</rule>
<rule id="commande" scope="public">
<ruleref uri="#action"/>
<ruleref uri="#objet"/>
</rule>
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.
La forme ABNF
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
*/
public $commande = $ac
