Le groupe de travail Voice Browser a tenté de développer des normes permettant un accès au Web au travers d'une
interaction verbale. La spécification du langage de balisage de synthèse vocale
qui est l'une de ces normes, décrit un langage de balisage riche fondé sur XML
pour assister la génération d'une voix synthétisée dans le cadre du Web et dans d'autres applications.
Le rôle essentiel du langage de balisage est d'offrir aux créateurs
de contenus synthétisables une méthode normalisée pour contrôler les aspects de la voix
tels que la prononciation,
le volume sonore,
la hauteur tonale,
le rythme, etc. entre différentes plateformes capables de synthèse vocale.
Statut de ce document
Cette section décrit le statut du document au moment de sa publication. D'autres documents peuvent venir le remplacer.
On peut trouver la liste des publications actuelles 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 constitue la spécification du langage de balisage de synthèse vocale (SSML) 1.0 qui est une
recommandation du W3C.
Il a été produit dans le cadre de l'activité Voice Browser.
Les auteurs du document participent au groupe de travail Voice Browser
(accès réservé au membres du W3C).
Pour plus de renseignements, consultez la FAQ Voice Browser.
Ce document est stable, et il a été approuvé par les membres du W3C et les participants du groupe de travail Voice Browser.
La conception de SSML 1.0 a été largement examinée (cf. la
mise à disposition des commentaires)
et elle satisfait aux exigences techniques du groupe de travail. Une liste de mises en œuvre est incluse dans le
rapport de mise en œuvre SSML 1.0,
avec la suite de tests associée.
Les commentaires sont les bienvenus sur la liste de diffusion www-voice@w3.org
(archives). Cf. les
conditions d'utilisation des listes de diffusion et des archives du W3C.
On peut trouver les divulgations de brevets concernant cette spécification sur la
page de divulgation de brevets du groupe de travail.
La publication de ce document a lieu selon la politique de brevets courante du 24 janvier 2002
amendée par la procédure de transition de la politique de brevets du W3C.
Quiconque aurait connaissance de l'existence d'un brevet censé contenir une ou plusieurs revendications essentielles à propos de
cette spécification devrait en faire la divulgation conformément au
chapitre 6 de la politique de brevets du W3C.
0. Table des matières
1. Introduction
La spécification du W3C, connue sous l'appellation langage de balisage de synthèse vocale (SSML),
est fondée sur les spécifications JSGF et/ou JSML,
propriétés de Sun Microsystems, Inc., California, U.S.A. On peut consulter la spécification JSML
à [JSML].
Le langage SSML fait partie d'un ensemble plus vaste de spécifications de balisage pour
navigateurs vocaux développées au travers des processus ouverts du W3C.
Il constitue un langage de balisage riche fondé sur XML pour assister la génération d'une voix synthétisée
dans le cadre du Web et dans d'autres applications. Le rôle essentiel du langage de balisage est de fournir aux
créateurs de contenus synthétisables une méthode normalisée pour contrôler les aspects de la voix tels que la prononciation,
le volume sonore, la hauteur tonale, le rythme, etc. entre différentes plateformes capables de synthèse vocale.
Le projet SABLE [SABLE] est une initiative apparentée pour établir un système de balisage normalisé
du texte d'entrée, qui essayait d'intégrer plusieurs balisages
de synthèse de la parole différents fondés sur XML.
L'activité du projet SABLE a également servi de point de départ principal pour définir Les besoins du balisage de synthèse vocale
des langages de balisage de la voix [REQS]. Le projet SABLE même n'a pas connu d'autres développements depuis.
Le langage SSML est conçu pour améliorer la qualité du contenu synthétisé. Divers éléments de balisage
agissent à des stades différents du processus de synthèse (cf. la section 1.2). Le balisage peut être produit
automatiquement, par exemple, via les feuilles de style XSLT
ou CSS3 d'un document XHTML,
ou bien être une création humaine. Il peut être présent dans un document SSML complet
(cf. la section 2.2.2) ou faire partie d'un fragment (cf. la section 2.2.1)
incorporé dans un autre langage, quoique la spécification SSML ne définisse aucune interaction avec d'autres langages.
La plupart des balises que contient SSML peut être utilisée par la majorité des développeurs de contenus,
toutefois certaines caractéristiques évoluées comme celles des éléments phoneme
et prosody (par exemple, pour créer un
profil vocal) nécessiteront peut-être des connaissances spécialisées.
1.1 Les concepts du modèle
Le processus de conception et de normalisation s'ensuit de Les besoins du balisage de synthèse vocale
des langages de balisage de la voix [REQS].
Les éléments suivants ont constitué les critères de conception clés :
- La cohérence : Fournir un contrôle prévisible de la sortie vocale entre plateformes et entre mises en œuvre de synthèse vocale ;
- L'interopérabilité : Permettre une utilisation conjointe avec d'autres spécifications du W3C
dont mais pas seulement VoiceXML, les feuilles de style CSS audio et SMIL ;
- La généralité : Permettre une sortie vocale pour une large gamme d'applications avec des contenus vocaux variés ;
- L'internationalisation : Permettre une sortie vocale dans un grand nombre de langues, au sein ou entre les documents ;
- La génération et la lisibilité : Permettre la génération automatique et la création manuelle des documents.
Le document devrait être lisible par un humain ;
- La mise en œuvre : La spécification devrait pouvoir être mise en œuvre avec les technologies existantes
disponibles partout, et le nombre de caractéristiques optionnelles devrait être minimal.
1.2 Les étapes du processus de synthèse vocale
Le synthétiseur texte-parole (ou
synthétiseur) gérant
le langage SSML est responsable de la restitution d'un document en sortie vocale et de l'utilisation des informations
contenues dans le balisage pour restituer le document selon l'intention de l'auteur.
La création du document : Le document textuel fourni en entrée au synthétiseur peut être
produit automatiquement, créé par un humain, ou une combinaison de ces deux formes. Le langage SSML définit la forme du document.
Le traitement du document : Les six étapes principales du traitement entrepris par le synthétiseur
pour convertir un texte d'entrée balisé en une sortie vocale générée automatiquement sont les suivantes. Le langage de balisage
est suffisamment riche pour contrôler chaque étape décrite ci-dessous, de sorte que l'auteur du document (homme ou machine)
peut maîtriser la sortie vocale finale. Bien que chaque étape se divise en une interprétation du balisage
et en comportement hors balisage
, le comportement réel est habituellement un mélange des deux, et il varie selon la balise.
Il revient au processeur de s'assurer que ce qu'il produit est prononçable (et idéalement intelligible). Le balisage représente en général
le moyen dont dispose l'auteur pour fournir des informations prosodiques ou autres au processeur, habituellement des informations
que le processeur ne saurait obtenir seul. Le processeur détermine alors s'il va utiliser ces informations et de quelle façon.
-
L'analyse XML : Un analyseur XML extrait l'arbre du document et son contenu du
document textuel entrant. La structure, les balises et les attributs
obtenus au cours de cette étape influencent chacune des suivantes. Les atomes (mots) dans SSML ne peuvent pas
s'étendre sur les éléments de balisage. L'exemple simple en français
car<break/>table
sera traité par le synthétiseur comme les deux mots car
et table
, et non comme un seul mot avec une pause au milieu. Ce découpage d'un atome en plusieurs affectera
vraisemblablement la façon dont le processeur le traitera.
-
L'analyse de structure : La structure du document influence la façon dont il devrait être lu. Par exemple,
il existe des formes oratoires communes associées aux paragraphes
et aux phrases.
-
Utilisation du balisage : Les éléments p
et s définis dans SSML indiquent explicitement
les structures de document affectant la sortie vocale.
-
Comportement hors balisage : Dans les documents et parties de documents où ces éléments ne sont pas utilisés, le
synthétiseur est tenu d'inférer la structure par une analyse automatisée du texte, la plupart du temps
en se servant de la ponctuation et d'autres données propres à la langue.
-
La normalisation du texte : Toutes les langues écrites possèdent
des structures particulières qui nécessitent une conversion de la forme écrite (forme orthographique) vers la forme parlée.
La normalisation du texte est un processus automatisé du synthétiseur réalisant cette conversion.
Par exemple, en anglais, si la chaîne $200
apparaît dans un document, elle peut se dire deux cents dollars
.
De même, la chaîne 1/2
peut se dire un demi
, le premier février
, un sur deux
, et ainsi de suite.
À la fin de cette étape, le texte à dire aura été entièrement converti en atomes. La constitution exacte d'un atome
est propre à la langue. En français, les atomes sont habituellement séparés par des blancs et forment typiquement des mots.
Pour les langues avec un comportement d'atomisation différent, le terme mot
dans cette spécification signifie
une unité comparable appropriée.
-
Utilisation du balisage : L'élément say-as peut servir
dans le document d'entrée pour indiquer explicitement la présence de telles structures et leur types, et pour lever les ambiguïtés.
L'ensemble des structures que l'on peut marquer n'a pas encore été défini mais il est susceptible d'inclure les dates, les heures,
les nombres, les sigles, les quantités monétaires, etc. Remarquez que l'auteur peut manipuler beaucoup de sigles et d'abréviations
par remplacement direct du texte ou par l'utilisation d'un élément sub, par exemple,
BBC
peut s'écrire B B C
et AAA
s'écrire trois A
. Ces formes écrites de remplacement seront vraisemblablement
prononcées de la façon dont on aurait voulu que les abréviations originales le soient. Dans le cas d'un texte japonais,
si le synthétiseur prend en charge à la fois le kanji et le kana, on peut se servir de
l'élément sub pour identifier si 今日は
devrait se dire
きょうは
(kyou wa
: aujourd'hui) ou bien こんにちは
(konnichiwa
: bonjour).
-
Comportement hors balisage : Pour un contenu textuel non marqué avec l'élément say-as,
le synthétiseur est censé faire un effort raisonnable pour localiser et convertir automatiquement
ces structures en des formes prononçables. À cause d'ambiguïtés inhérentes (comme dans l'exemple précédent avec 1/2
)
et de la gamme étendue des structures possibles dans une langue, ce processus peut introduire des erreurs en sortie vocale
et faire que des processeurs différents restituent le même document différemment.
-
La conversion texte-phonème :
Une fois que le synthétiseur a déterminé l'ensemble des mots à dire,
il doit déduire les prononciations de chaque mot. Les prononciations des mots peuvent être décrites en pratique comme des
séquences de phonèmes, lesquels sont les unités de son dans une langue servant à distinguer un mot d'un autre.
Chaque langue (et parfois, chaque variante nationale ou dialecte de langue) possède un ensemble de phonèmes spécifique ;
par exemple, la plupart des dialectes anglo-américains ont environ 45 phonèmes, le hawaïen en a entre 12 et 18 (selon l'interlocuteur),
et d'autres en ont plus de 100 ! Cette conversion est rendue complexe par un certain nombre de facteurs. Un premier facteur
est celui selon lequel les formes écrites et parlées d'une langue peuvent être différentes, et cette différence peut amener
une indétermination ou une ambiguïté dans la prononciation des mots écrits. Par exemple, comparés à leurs formes parlées,
les mots hébreux et arabes s'écrivent sans voyelle ou seulement avec quelques voyelles définies. Dans beaucoup de langues,
le même mot écrit peut avoir plusieurs formes parlées. Par exemple, en anglais, le mot read
peut se prononcer
ride (I will read the book)
ou raide (I have read the book)
.
Les locuteurs humains et les synthétiseurs peuvent prononcer correctement ces mots selon le contexte mais avoir des difficultés
à le faire en absence de contexte (cf. Comportement hors balisage
ci-dessous). Un autre facteur est celui
de la gestion des mots avec des orthographes ou des prononciations irrégulières. Ainsi, un synthétiseur
anglais aura souvent des difficultés à déterminer comment dire certains noms d'origine étrangère, par exemple,
Caius College
(prononcé kîz collidje
), President Tito
(prononcé çeuto
,
Republic of Kiribati
(prononcé kiribass
), etc.
-
Utilisation du balisage : L'élément phoneme
permet de fournir une séquence phonémique pour chaque mot ou séquence de mots. Il donne au créateur de contenu le contrôle explicite
des prononciations. L'élément say-as peut aussi servir à indiquer que le texte
est un nom propre, ce qui permet au synthétiseur d'appliquer des règles de prononciation particulières.
L'élément lexicon peut être utilisé pour appeler des définitions
de prononciations externes. Ces éléments peuvent se révéler particulièrement utiles pour les sigles et abréviations
que le synthétiseur n'est pas capable de résoudre au travers de sa propre normalisation de texte
et qu'il n'est pas possible de traiter par remplacement direct du texte ou par l'élément sub
(cf. le paragraphe 3 précédent).
-
Comportement hors balisage : En absence d'éléments phoneme, le
synthétiseur doit appliquer des techniques automatiques afin de déterminer les prononciations.
Il y parvient habituellement en consultant des mots dans un dictionnaire de prononciation (qui peut dépendre de la langue)
et en appliquant des règles pour déterminer les autres prononciations. Les synthétiseurs sont conçus
pour réaliser des conversions texte-phonème, de sorte que, dans beaucoup de documents, la manipulation de la plupart des mots peut avoir lieu
automatiquement. Hormis le fait de compter sur le synthétiseur, l'auteur peut soi-même choisir de faire certaines conversions
préalablement au codage SSML. Il remplacera peut-être les mots écrits, dont la prononciation est indéterminée ou ambiguë,
par des mots dont la prononciation ne l'est pas ; par exemple, dans le cas du read
précédent, écrire I will reed the book
.
Toutefois, l'auteur devrait tenir compte du fait que le rendu visuel des documents SSML produits ainsi est loin d'être parfait.
-
Analyse de la prosodie : La prosodie est l'ensemble des caractéristiques de sortie vocale, comprenant la hauteur tonale (aussi
appelée intonation ou mélodie), la synchronisation,
les pauses,
le rythme de parole,
l'emphase des mots,
et beaucoup d'autres. La production d'une prosodie pareille à celle d'un humain est importante pour que la parole sonne naturellement
et pour que la communication du sens de la parole soit correcte.
-
Utilisation du balisage : Les éléments emphasis,
break et prosody sont tous utilisables
par les créateurs de documents pour guider le synthétiseur dans la génération de caractéristiques prosodiques
appropriées pour la sortie vocale.
-
Comportement hors balisage : En l'absence de ces éléments, les synthétiseurs sont des experts
(imparfaits) pour générer automatiquement une prosodie qui convienne. Ils y parviennent en analysant la structure du document,
la syntaxe de la phrase et d'autres informations déductibles du texte en entrée.
Bien qu'on puisse considérer la plupart des éléments de SSML être de niveau supérieur, dans la mesure où ils fournissent
soit un contenu à dire, soit des descriptions logiques du style, les éléments break et
prosody, vu précédemment, interviennent plus tard dans le processus, ce qui les fait
coexister à la fois avec les éléments emphasis et les propres déterminations prosodiques
du synthétiseur. Sauf indication contraire dans les sections concernées, les interactions entre les déterminations du synthétiseur
et celles fournies par l'auteur à ce niveau dépendent du processeur. Les auteurs sont encouragés à ne pas mélanger ces deux niveaux de contrôle,
que ce soit occasionnellement ou bien arbitrairement.
-
Production de la forme d'onde : Les phonèmes et les informations prosodiques sont utilisés par le
synthétiseur pour produire la forme d'onde acoustique.
Cette étape du traitement peut être approchée de plusieurs façons et il peut donc y avoir des variations considérables selon les processeurs.
1.3 La génération du document, les applications et les contextes d'utilisation
Il y a plusieurs types de créateurs de documents susceptibles de produire des documents balisés à dire par un synthétiseur.
Les créateurs de documents (humains ou mécaniques) n'ont pas tous accès à des informations utilisables dans tous les éléments
ou à chaque étape du traitement décrite dans la section précédente. Voici quelques cas courants :
-
Le créateur du document ne dispose pas d'informations pour baliser le texte. Toutes les étapes de traitement, dans le
synthétiseur, doivent se dérouler de façon entièrement automatique sur du
texte brut. Seule la présence de l'élément conteneur speak
est nécessaire pour indiquer un contenu à dire ;
-
Lorsqu'un programme génère le texte balisé, il peut avoir une connaissance particulière de la structure et/ou des
locutions spéciales dans certains ou tous les documents. Par exemple, un lecteur de courrier électronique
peut marquer l'emplacement de l'heure et de la date de réception du message. De telles applications peuvent utiliser des éléments
qui affectent la structure, la normalisation de texte, la prosodie et parfois la conversion texte-phonème
-
Certains créateurs de documents font des efforts considérables pour marquer autant de détails du document que possibles pour assurer une
qualité de parole constante entre les plateformes et pour définir des qualités plus précises en sortie. Auquel cas,
le balisage peut utiliser une partie ou tous les éléments disponibles pour contrôler précisément la sortie vocale. Par exemple, les
invites générées dans les applications de téléphonie et de
navigation vocale peuvent être ajustées pour maximiser l'efficacité du système global ;
-
Les créateurs de documents plus sophistiqués peuvent sauter le balisage de haut niveau (la structure, la
normalisation de texte, la conversion texte-phonème et l'analyse prosodique) et produire un balisage de
synthèse vocale de bas niveau pour des segments de document ou pour des documents entiers. Des outils sont
généralement nécessaires pour générer les séquences de phonèmes, auxquelles s'ajoutent les informations de tonalité et de synchronisation.
Par exemple, les outils produisant une synthèse par copie
ou une
transposition de prosodie
essayent d'émuler la parole humaine
en copiant les propriétés d'enregistrements.
Voici des points importants concernant les architectures ou les constructions d'après lesquelles seront générés
les documents de synthèse balisés. La conception du langage est prévue afin de faciliter chacune de ces approches :
-
Langage de dialogue : Il est nécessaire de pouvoir inclure des documents marqués avec SSML
dans le document de description de dialogue restant à produire par le groupe de travail Voice Browser ;
-
Interopérabilité avec les feuille de style audio (ACSS) : Tout processeur HTML
capable d'interpréter une feuille de style audio peut produire un document SSML. Les feuilles de style ACSS
sont décrites dans le chapitre 19 de la spécification des feuilles de style en cascade niveau 2 (CSS2)
[CSS2 §19]. Cet emploi d'une synthèse vocale permet d'améliorer l'accessibilité
des contenus HTML et XHTML existants ;
-
Traitement spécifique des feuilles de style par l'application : Comme indiqué précédemment, il existe des classes d'applications
ayant une connaissance du contenu textuel à dire et pouvant être incorporées au balisage de synthèse vocale
pour améliorer la restitution du document. Dans beaucoup de cas, on attend de l'application qu'elle se serve des feuilles de style
pour effectuer la transformation vers SSML de documents XML existants. Cela équivaut à utiliser des feuilles de style ACSS
avec HTML, et la représentation résultante sera une fois encore du code SSML à passer au synthétiseur.
Dans ce contexte, on peut assimiler SSML à un surensemble des possibilités ACSS
[CSS2 §19], la spatialisation sonore mise à part.
1.4 Le comportement de sortie du contenu SSML dépendant de la plateforme
Le langage SSML offre une méthode normalisée pour définir les propriétés globales
de la production d'une voix synthétisée tels que la prononciation, le volume, la hauteur tonale, le rythme, etc. Par contre, la définition précise
du comportement en sortie d'une voix synthétisée entre des processeurs disparates n'est pas traitée dans ce document.
Sauf indication contraire, les valeurs de balisage sont simplement des indications plutôt que des absolus. Par exemple, un auteur peut
indiquer explicitement la durée d'un segment de texte et aussi la durée explicite d'un sous-ensemble de ce segment. Si les deux durées
combinées font que le synthétiseur ne peut pas raisonnablement restituer le segment, alors
il peut modifier au besoin ces durées pour la restitution.
1.5 La terminologie
- Terminologie des besoins
- Les mots-clés
DOI(VEN)T
, NE DOI(VEN)T PAS
, OBLIGATOIRE
, DEVRA(ONT)
, NE DEVRA(ONT) PAS
,
DEVRAI(EN)T
, NE DEVRAI(EN)T PAS
, RECOMMANDÉ
, PEU(VEN)T
et OPTIONNEL
sont à interpréter selon le document
[RFC2119]. Toutefois, pour la lisibilité, ces mots n'apparaissent pas en majuscules dans cette spécification.
- Adresse URI
- Une adresse URI est une syntaxe d'unification pour exprimer des noms et adresses d'objets sur le réseau comme utilisée sur
le Web. On définit une adresse URI être toute primitive légale de type
anyURI
tel que défini
dans la spécification XML Schema tome 2 : les types de données [SCHEMA2 §3.2.17].
Pour information seulement, les documents [RFC2396] et [RFC2732] seront peut-être utiles
pour comprendre la structure, le format et l'utilisation des adresses URI. Tout appel d'adresse URI relative
doit se résoudre d'après les règles données dans la section 3.1.3.1. Dans cette spécification, les adresses URI
apparaissent comme attributs d'éléments, par exemple, dans les éléments audio
et lexicon.
- Au gré de l'utilisateur
- Un synthétiseur conforme peut ou doit (selon le verbe modal dans la phrase) se comporter comme décrit ;
si c'est le cas, il doit alors proposer à l'utilisateur un moyen d'activer ou de désactiver le comportement en question.
- Condition d'erreur
- Le résultat n'est pas défini. Un synthétiseur conforme peut détecter et signaler une erreur,
et reprendre sur cette erreur.
- Navigateur vocal
- Un appareil interprétant un langage de balisage (vocal) et capable de générer une sortie vocale et/ou d'interpréter une
entrée vocale, et éventuellement d'autres modalités d'entrée/sortie.
- Synthèse texte-parole
- Le processus de génération automatique d'une sortie vocale à partir d'un texte d'entrée, annoté ou non.
- Synthèse vocale
- Le processus de génération automatique d'une sortie vocale à partir de données d'entrée composées de texte brut, de texte balisé
ou d'objets binaires.
- Synthétiseur
- Un système de synthèse texte-parole acceptant des documents SSML en entrée et les restituant
au travers d'une sortie parlée.
- Type de média
- Un type de média (décrit dans [RFC2045] et [RFC2046]) définit 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édia enregistrés
[TYPES]. Cf. l'annexe C pour des renseignements sur les types de média pour SSML.
2. Les documents SSML
2.1 La forme du document
Un document SSML autonome légal doit avoir un prologue XML légal
[XML §2.8]. La déclaration de type de document (DOCTYPE) optionnelle, si présente, doit être la suivante :
<!DOCTYPE speak PUBLIC "-//W3C//DTD SYNTHESIS 1.0//EN"
"http://www.w3.org/TR/speech-synthesis/synthesis.dtd">
Le prologue XML est suivi de l'élément racine speak.
Cf. la section 3.1.1 pour des précisions à propos de cet élément.
L'élément speak doit indiquer l'espace de nommage SSML.
Pour ce faire, on déclare un attribut xmlns, ou un attribut avec le préfixe xmlns
.
Cf. [XMLNS §2] pour des précisions. Remarquez que l'attribut xmlns est utilisé seul,
il établit l'espace de nommage par défaut de l'élément sur lequel il apparaît et pour tous ses sous-éléments.
La définition de l'espace de nommage SSML se trouve à :
http://www.w3.org/2001/10/synthesis.
Il est également recommandé que l'élément speak indique l'emplacement
du schéma SSML (cf. l'annexe D) via
l'attribut xsi:schemaLocation
défini dans [SCHEMA1 §2.6.3]. Bien que cette indication ne soit pas obligatoire, le présent document
l'utilise dans tous les exemples pour en encourager l'utilisation.
Voici deux exemples d'en-tête SSML légales :
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<?xml version="1.0"?>
<!DOCTYPE speak PUBLIC "-//W3C//DTD SYNTHESIS 1.0//EN"
"http://www.w3.org/TR/speech-synthesis/synthesis.dtd">
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xml:lang="en-US">
Les éléments meta, metadata et
lexicon doivent apparaître avant tous les autres éléments et le texte contenu dans
l'élément racine speak. Cette spécification n'impose pas d'autres contraintes d'ordre
d'apparition des éléments.
2.2. La conformité
2.2.1 Les fragments SSML conformes
Un fragment de document est un fragment SSML conforme si :
- Il satisfait aux critères d'un document SSML autonome conforme après que :
- Les attributs
xml:lang et
xml:base mis à part, tous les éléments et attributs n'appartenant pas à
l'espace de nommage SSML et tous les attributs xmlns se rapportant à des éléments hors de
l'espace de nommage SSML ont été supprimés du document ;
- Et, si l'élément
speak n'indiquait pas déjà l'espace de nommage SSML
par l'attribut xmlns, la déclaration xmlns="http://www.w3.org/2001/10/synthesis"
lui est alors ajoutée.
2.2.2 Les documents SSML autonomes conformes
Un document est un document SSML autonome conforme s'il satisfait aux deux conditions suivantes :
La spécification SSML et ces critères de conformité n'instaurent aucune limitation de taille concernant un aspect quelconque
des documents SSML. Il n'y a pas de valeur maximale du nombre d'éléments, de la quantité de données textuelles
ou du nombre de caractères des valeurs d'attributs.
2.2.3 L'utilisation de SSML avec d'autres espaces de nommage
L'espace de nommage SSML peut être utilisé en même temps que d'autres espaces de nommage XML, comme défini
dans la recommandation des espaces de nommage XML [XMLNS]. Il est prévu que des développements futurs
du W3C établissent des méthodes permettant de définir la conformité de documents avec plusieurs espaces de nommage.
2.2.4 Les processeurs SSML conformes
Un processeur SSML est un programme capable d'analyser et de traiter un document SSML autonome conforme.
L'analyseur XML du processeur SSML conforme doit être capable d'analyser et de traiter
toutes les structures XML définies dans la recommandation XML 1.0 [XML] et dans celle
des espaces de nommage dans XML [XMLNS]. L'analyseur XML n'est pas tenu de réaliser
une validation du document SSML contre son schéma ou sa définition DTD ; il découle que,
pendant le traitement d'un document SSML, l'application ou la résolution d'appels d'entités décrites dans une
définition DTD externe sont optionnels.
Un processeur SSML conforme doit interpréter et appliquer correctement la sémantique de chaque élément de balisage,
comme décrit dans ce document.
Un processeur SSML conforme doit remplir les conditions suivantes pour manipuler des langues naturelles (humaines) :
- Le processeur SSML conforme doit réussir à analyser toutes les déclarations de langues naturelles ;
- Le processeur SSML conforme peut avoir la capacité d'appliquer la sémantique de langages de balisage en rapport avec
plusieurs langues naturelles. S'il est capable de gérer chaque langue naturelle de cet ensemble mais pas toutes en même temps,
alors il devrait en informer l'environnement hôte ;
- Le processeur SSML conforme peut mettre en œuvre les langues naturelles par des substitutions approximatives selon
un comportement documenté spécifique. Par exemple, un synthétiseur anglais américain pourrait traiter une entrée en anglais britannique ;
Lorsqu'un processeur SSML conforme rencontre des éléments ou attributs, hormis les attributs
xml:lang et xml:base,
dans un espace de nommage non-SSML, il peut :
- Ignorer ces éléments et/ou attributs non normalisés, ou ;
- Traiter ces éléments et/ou attributs non normalisés, ou ;
- Rejeter le document contenant ces éléments et/ou attributs.
Par contre, il n'y a aucune condition de conformité pour les caractéristiques de fonctionnement du processeur SSML.
Par exemple, aucune déclaration n'est nécessaire concernant l'exactitude, la vitesse ou les autres caractéristique de la parole produite
par le processeur. Aucune mention n'est faite de la taille admissible de l'entrée d'un processeur SSML.
2.2.5 Les agents utilisateurs conformes
Un agent utilisateur conforme est un processeur SSML conforme apte à recevoir
un document SSML en entrée et à produire une sortie vocale en utilisant les informations contenues dans le balisage
afin de restituer le document selon l'intention de l'auteur. Un agent utilisateur conforme doit gérer au moins une langue naturelle.
Puisqu'on ne peut pas garantir une représentation exacte en sortie de tout le balisage contenu dans l'entrée, aucune obligation de conformité
ne s'applique donc en ce qui concerne l'exactitude de la restitution. Toutefois, un test de conformité peut imposer quelques exemples
de synthèse correcte d'un document de référence pour déterminer une conformité.
2.3 L'intégration à d'autres langages de balisage
Le langage d'intégration multimédia synchronisé (SMIL, prononcé smaïle
) [SMIL]
permet de créer simplement des présentations audiovisuelles interactives. On l'utilise habituellement pour les présentations média riche
/multimédia
contenant un flux audio et vidéo avec des images, du texte ou tout autre type de média. SMIL est un langage comme HTML,
d'apprentissage facile, et beaucoup de présentations SMIL sont écrites avec un éditeur de texte simple.
Cf. les exemples d'intégration SMIL/SSML dans l'annexe F.
Les feuilles de style audio (ACSS) [CSS2 §19]
servent à augmenter les formes visuelles normales des documents (par exemple, un document HTML) par d'autres éléments
assistant la synthèse sonore du texte. Comparés à SSML, les documents générés avec ACSS sont capables de
définitions plus complexes de la séquence audio, dont la position spatiale de la source sonore. Beaucoup d'autres éléments ACSS
recouvrent des fonctionnalités SSML, notamment pour la définition du type et de la qualité de la voix.
On peut assimiler SSML à un surensemble des possibilités ACSS, la spatialisation du son mise à part.
Le langage de balisage extensible vocal (VoiceXML) [VXML]
permet le développement et le transport de contenu par le Web pour des applications à réponse vocale interactives
(cf. l'entrée navigateur vocal ). Le langage VoiceXML gère
la synthèse vocale, l'enregistrement et la lecture de sons numériques, la reconnaissance vocale,
les tonalités DTMF en entrée, le contrôle des appels en téléphonie
et les dialogues à initiative mixte dirigés par formulaire. Le langage VoiceXML 2.0 complète SSML
pour le balisage du texte à synthétiser. Cf. l'annexe F pour un exemple d'intégration entre VoiceXML et SSML.
2.4 La récupération des documents SSML
La récupération et le comportement de mise en cache des documents SSML est défini par l'environnement dans lequel le
synthétiseur opère. Par exemple, dans un contexte d'interprétation VoiceXML,
la politique de mise en cache est déterminée par l'interpréteur VoiceXML.
3. Les éléments et attributs
Cette spécification définit les éléments et attributs suivants :
3.1 La structure du document, le traitement du texte et la prononciation
Le langage SSML est une application XML. L'élément racine est l'élément speak.
L'attribut obligatoire xml:lang définit la langue du document racine.
L'attribut optionnel xml:base définit l'adresse URI de base
du document racine. L'attribut obligatoire version indique la version de la spécification à utiliser pour le document,
et il doit valoir "1.0".
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
... le corps ...
</speak>
L'élément speak peut seulement contenir du texte à restituer et/ou les éléments suivants :
audio, break,
emphasis, lexicon,
mark, meta,
metadata, p,
phoneme, prosody,
say-as, sub,
s, voice.
L'attribut xml:lang, comme défini dans la
spécification XML 1.0 [XML §2.12], peut servir à indiquer dans SSML la langue de l'élément
englobant et ses attributs ainsi que de ses sous-éléments. Le document RFC 3066 [RFC3066] peut se révéler utile
pour comprendre l'utilisation de cet attribut.
L'information de langue est héritée en descendant la hiérarchie du document, c'est-à-dire qu'il suffit de le donner une seule fois
si la totalité du document est dans une seule langue, et elle peut être imbriquée, c'est-à-dire que les attributs intérieurs écrasent les extérieurs.
L'attribut xml:lang s'applique aux éléments
voice, speak,
p et s.
Dans la restitution vocale, un changement de langue peut affecter divers autres paramètres (dont le genre, la vitesse, l'âge, la hauteur tonale, etc.),
ce qui peut perturber l'auditeur. Des interruptions non naturelles peuvent même avoir lieu entre les glissements de langue. Pour ces raisons,
les auteurs sont invités à utiliser l'élément voice pour changer de langue.
L'attribut xml:lang est admis sur les
éléments p et s seulement
parce que les changements de langues sont courants à ces niveaux.
Bien que l'attribut soit également permis sur l'élément desc, aucun des comportements
de changements de voix décrits dans cette section ne s'applique quand il est utilisé avec cet élément.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<p>Je ne parle pas japonais.</p>
<p xml:lang="ja">日本語が分かりません。</p>
</speak>
Si un document demande une sortie vocale dans une langue non gérée par le processeur, le comportement sera largement déterminé par le
synthétiseur. Une définition d'attribut xml:lang
n'implique pas un changement de voix, quoique cela puisse effectivement arriver. Lorsqu'une voix donnée n'est pas apte à dire un
contenu dans la langue indiquée, le processeur peut en sélectionner une nouvelle. Aucun changement ne devrait intervenir dans la voix
ou la prosodie si la valeur courante de l'attribut xml:lang est identique à celle héritée.
On trouvera des informations complémentaires concernant la sélection d'une voix dans la section 3.2.1.
La mise en œuvre des changements de voix avec l'attribut xml:lang
peut varier d'un processeur conforme à l'autre pour des éléments de balisage différents (par exemple,
les éléments p et s).
Tous les éléments devraient traiter leur contenu en fonction de la langue englobante. Par exemple, les
éléments phoneme, emphasis,
break, p et
s devraient chacun être restitués de façon appropriée pour la langue courante.
La langue courante peut affecter l'étape de traitement de normalisation de texte.
C'est le cas pour la gestion du balisage par l'élément say-as et pour le comportement
hors balisage. Dans l'exemple suivant, le même texte 2/1/2000
peut se lire February first two thousand
dans la première phrase
régie par les règles de prononciation anglaises américaines, mais le deux janvier deux mille
(en italien) dans la seconde phrase régie
par les règles italiennes de prétraitement.
<?xml version="1.0" encoding="ISO-8859-1"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<s>Today, 2/1/2000.</s>
<!-- Today, February first two thousand -->
<s xml:lang="it">Un mese fà, 2/1/2000.</s>
<!-- Un mese fà, il due gennaio duemila -->
<!-- Il y a un mois, le deux janvier deux mille -->
</speak>
3.1.3 L'adresse URI de base : l'attribut xml:base
Les adresses URI relatives se résolvent par rapport à une adresse URI de base,
laquelle peut provenir de plusieurs sources. La déclaration de l'adresse URI de base permet à l'auteur de définir explicitement
l'adresse URI de base du document. Cf. la section 3.1.3.1 pour des précisions
sur la résolution des adresses URI relatives.
La déclaration d'adresse URI de base est permise mais optionnelle.
Les deux éléments qu'elle affecte sont les suivants :
audio- L'attribut optionnel
src peut indiquer une adresse URI relative.
lexicon- L'attribut
uri peut indiquer une adresse URI relative.
La déclaration d'adresse URI de base obéit à la recommandation [XML-BASE] ;
elle se manifeste au travers d'un attribut xml:base sur l'élément racine speak.
<?xml version="1.0"?>
<speak version="1.0" xml:lang="fr"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:base="http://www.example.com/chemin-du-fichier-de-base">
<?xml version="1.0"?>
<speak version="1.0" xml:lang="fr"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:base="http://www.example.com/autre-chemin-du-fichier-de-base">
3.1.3.1 La résolution des adresses URI relatives
Les agents utilisateurs doivent calculer l'adresse URI de base pour résoudre les adresses URI relatives
conformément au document [RFC2396]. Voici comment l'appliquer aux documents de synthèse vocale.
Les agents utilisateurs doivent entreprendre le calcul de l'adresse URI de base dans l'ordre de priorité suivant (du plus au moins prioritaire) :
- L'adresse URI de base est fixée par l'attribut
xml:base sur
l'élément speak (cf. section 3.1.3) ;
- L'adresse URI de base est fournie par les métadonnées découvertes au cours d'un échange protocolaire, telle qu'une
en-tête HTTP (cf. [RFC2616]) ;
- Par défaut, l'adresse URI de base est celle du document courant. Les documents de synthèse vocale n'ont pas tous
une adresse URI de base (par exemple, un document de synthèse vocal peut apparaître dans un courrier électronique
sans être désigné par une adresse URI). Une condition d'erreur apparaît
lorsque de tels documents contiennent des adresses URI relatives.
3.1.4 Le lexique de prononciation : l'élément lexicon
Un document SSML peut appeler un ou plusieurs lexiques de prononciation externes. On identifie un document de lexique par
une adresse URI et un type de média optionnel.
Il n'a pas encore été défini de type de média normalisé par défaut pour les lexiques pour cette spécification.
Le groupe de travail Voice Browser du W3C poursuit le développement de la spécification du langage de balisage des lexiques de prononciation
[LEX]. Elle doit régler les questions concernant le processus de correspondance entre les atomes et les entrées de lexique,
et le mécanisme par lequel le synthétiseur gérera plusieurs prononciations d'après les lexiques internes
et ceux définis par la synthèse. La gestion des prononciations au travers de formats de lexiques propriétaires sera forcément spécifique
au synthétiseur en question.
Un document de lexique contient des données de prononciation pour les atomes apparaissant dans le texte à dire.
Ces informations dans le lexique servent pour les atomes contenus dans le document appelant.
Les lexiques de prononciation sont forcément spécifiques à une langue. La consultation dans un lexique et
l'inférence de la prononciation d'un atome peuvent utiliser un algorithme spécifique à la langue.
Comme indiqué dans la section 1.2, la définition même de la nature d'atome
peut être spécifique à la langue.
Lorsque plusieurs lexiques sont appelés, leur priorité augmente en avançant dans le document. Il s'agit ici de l'atome
à rechercher en priorité dans le lexique. S'il ne s'y trouve pas, le lexique suivant est exploré,
et ainsi de suite, jusqu'à la première correspondance ou jusqu'à épuisement de tous les lexiques utilisés pour la recherche.
L'élément speak admet un nombre quelconque de
sous-éléments lexicon immédiats. L'élément lexicon
doit avoir un attribut uri pour indiquer l'adresse URI où trouver
le 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.
<?xml version="1.0"?>
<!DOCTYPE speak PUBLIC "-//W3C//DTD SYNTHESIS 1.0//EN"
"http://www.w3.org/TR/speech-synthesis/synthesis.dtd">
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<lexicon uri="http://www.example.com/lexique.fichier"/>
<lexicon uri="http://www.example.com/mots-curieux.fichier"
type="type-de-média"/>
...
</speak>
Précisions sur l'attribut type
Remarque : La description et le tableau suivants utilisent le type de lexique d'un vendeur imaginaire x-vnd.example.lexique
.
Ceci pour représenter si besoin tout format renvoyé/disponible.
Une ressource de lexique, désignée par un appel d'adresse URI, peut être disponible dans plusieurs
types de média. L'auteur SSML peut indiquer le type de média préféré via l'attribut type.
Lorsque le contenu représenté par une adresse URI est disponible en plusieurs formats de données, le
synthétiseur peut utiliser le type préféré afin d'influencer le choix du format à utiliser. Par exemple,
sur un serveur capable d'une négociation de contenu HTTP, le processeur peut utiliser le type pour déterminer des préférences
pendant ladite négociation.
À réception, la ressource désignée par un appel d'adresse URI peut être classée en deux types : le
type de média déclaré, qui est la valeur d'allégation de la ressource,
et le type de média réel, qui est le format véritable de son contenu. Le type réel
devrait être identique au type déclaré, mais ce n'est pas toujours le cas (par exemple, un serveur HTTP mal configuré
pourrait renvoyer le type text/plain
pour un document au lieu du type du format spécifique du vendeur x-vnd.example.lexique
).
Un système d'addressage URI particulier peut, selon les cas, imposer au propriétaire
de la ressource de toujours renvoyer un type de média, ou bien parfois, ou bien jamais. Dès lors qu'un type de média est renvoyé,
il fait autorité. Le type de média déclaré est déterminé d'après la valeur renvoyée par le propriétaire de la ressource ou,
si rien n'est renvoyé, par le type de média préféré fourni dans le document SSML.
Trois cas particuliers peuvent se présenter : le type déclaré n'est pas géré par le processeur et il y a
condition d'erreur ; le type déclaré est géré mais le type réel ne correspond pas, et il y a aussi
condition d'erreur ; enfin aucun type de média n'est déclaré et le comportement dépend alors du
système d'adressage URI particulier et des capacités du synthétiseur. Par exemple,
le protocole HTTP 1.1 permet une introspection du document (cf. [RFC2616 §7.2.1]),
ou encore le schéma de données se replie sur un type de média par défaut, ou encore la
méthode d'accès local ne définit aucune solution.
Le tableau suivant fournit quelques exemples informatifs :
Exemples pour le type de média
|
Requête HTTP 1.1 |
Méthode d'accès local |
| Type de média renvoyé par le propriétaire de la ressource |
text/plain |
x-vnd.example.lexique |
<aucun> |
<aucun> |
| Type de média préféré dans le document SSML |
Ne s'applique pas ; le type renvoyé fait autorité. |
x-vnd.example.lexique |
<aucun> |
| Type de média déclaré |
text/plain |
x-vnd.example.lexique |
x-vnd.example.lexique |
<aucun> |
| Comportement pour le type réel x-vnd.example.lexique |
Le document doit être traité comme étant de type "text/plain". Si le type "text/plain" n'est pas géré, ou si le document ne
respecte pas le format attendu, il y a alors condition d'erreur. |
Le type déclaré et le type réel correspondent ; succès si x-vnd.example.lexique est géré par le synthétiseur, sinon il y a
condition d'erreur. |
Propre au système ; le synthétiseur peut examiner le contenu du document pour en déterminer le type. |
L'élément lexicon est un élément vide.
Les éléments metadata et meta
sont des conteneurs où l'on peut placer des informations à propos du document.
L'élément metadata permet un traitement plus général et plus puissant des métadonnées que
l'élément meta car il utilise un schéma de métadonnées.
Une déclaration meta associe une chaîne à un attribut meta
déclaré, ou bien déclare un contenu http-equiv. L'un ou l'autre attribut name
ou http-equiv est obligatoire. Il y a condition d'erreur si les deux
attributs name et http-equiv sont présents. L'attribut content
est obligatoire. La propriété seeAlso est le seul nom de propriété défini pour l'élément meta.
Cette propriété sert à désigner une ressource susceptible d'apporter des métadonnées supplémentaires à propos du contenu.
Elle s'inspire de la propriété seeAlso
du schéma du cadre de description de ressources (RDF 1.0)
[RDF-SCHEMA §5.4.1]. L'attribut http-equiv prend une importance spéciale pour les
documents récupérés via le protocole HTTP. Quoique les champs d'en-têtes HTTP constituent la méthode préférée
pour fournir des informations d'en-têtes HTTP, l'auteur du document SSML peut mettre à profit
le contenu de l'attribut http-equiv s'il n'a pas la possibilité de configurer les champs d'en-tête HTTP
associés à ses documents sur le serveur origine, par exemple, les instructions de mise en cache. Remarquez que les serveurs et caches HTTP
ne sont pas obligés d'examiner le contenu des éléments meta dans les documents SSML
et d'écraser en conséquence les valeurs d'en-têtes qu'ils auraient sinon envoyées.
Pour information : Voici un exemple d'inclusion d'éléments meta dans un document SSML
afin d'y indiquer une ressource offrant des métadonnée supplémentaires et que le document ne doit pas être mis en cache :
<?xml version="1.0"?>
<!DOCTYPE speak PUBLIC "-//W3C//DTD SYNTHESIS 1.0//EN"
"http://www.w3.org/TR/speech-synthesis/synthesis.dtd">
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<meta name="seeAlso" content="http://example.com/mes-metadonnees-ssml.xml"/>
<meta http-equiv="Cache-Control" content="no-cache"/>
</speak>
L'élément meta est un élément vide.
L'élément metadata est un élément dans lequel on peut placer des informations
à propos du document en utilisant un schéma de métadonnée. Bien que n'importe quel schéma de métadonnée puisse être employé avec
l'élément metadata, on recommande d'utiliser conjointement la syntaxe XML
du cadre de description de ressources (RDF) [RDF-XMLSYNTAX] et les propriétés de métadonnées générales
définies par l'initiative Dublin Core [DC].
Le cadre de description de ressources [RDF] est un langage déclaratif fournissant une méthode normalisée XML
pour représenter les métadonnées sous forme de déclarations sur les propriétés et relations des éléments sur le Web. Les créateurs de contenus
devraient consulter les recommandations du W3C sur les métadonnées ([RDF-XMLSYNTAX] et
[RDF-SCHEMA]) pour décider quel schéma RDF de métadonnées employer dans leurs documents.
Il devraient également consulter l'initiative Dublin Core [DC], qui établit un ensemble de propriétés de métadonnées
de base d'utilisation générale (par exemple, Title
, Creator
, Subject
, Description
, Rights
, etc.).
Les propriétés du document déclarées par l'élément metadata peuvent utiliser
n'importe quel schéma de métadonnées.
Pour information : Voici un exemple d'inclusion d'un élément metadata
dans un document SSML, en utilisant le schéma RDF de l'initiative Dublin Core version 1.0 [DC]
pour décrire des informations générales à propos du document, tels que le titre, la description, la date, et ainsi de suite :
<?xml version="1.0"?>
<!DOCTYPE speak PUBLIC "-//W3C//DTD SYNTHESIS 1.0//EN"
"http://www.w3.org/TR/speech-synthesis/synthesis.dtd">
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<metadata>
<rdf:RDF
xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
xmlns:dc = "http://purl.org/dc/elements/1.1/">
<!-- Métadonnées sur le document de synthèse vocale -->
<rdf:Description rdf:about="http://www.example.com/meta.ssml"
dc:Title="Soliloque à la Hamlet"
dc:Description="Le soliloque d'Aldine dans le style de Hamlet"
dc:Publisher="W3C"
dc:Language="fr"
dc:Date="2002-11-29"
dc:Rights="Copyright 2002 Aldine Turnbet"
dc:Format="application/ssml+xml" >
<dc:Creator>
<rdf:Seq ID="NomCreateursOrdreAlphabetique">
<rdf:li>William Shakespeare</rdf:li>
<rdf:li>Aldine Turnbet</rdf:li>
</rdf:Seq>
</dc:Creator>
</rdf:Description>
</rdf:RDF>
</metadata>
</speak>
Le contenu de l'élément metadata peut être arbitraire, toutefois le
synthétiseur n'en restituera aucune partie.
3.1.7 La structure du texte : les éléments p et s
L'élément p représente un paragraphe et
l'élément s une phrase.
L'atttribut xml:lang est défini pour les
éléments p et s.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<p>
<s>Voici la première phrase du paragraphe.</s>
<s>Et une autre.</s>
</p>
</speak>
Les éléments p et s
sont optionnels. Lorsque du texte se présente sans élément p (ou
s) englobant, le synthétiseur devrait essayer
d'en déterminer la structure, en utilisant une connaissance spécifique à la langue du format du texte ordinaire.
L'élément p peut seulement contenir du texte à restituer et/ou les éléments suivants :
audio, break,
emphasis, mark,
phoneme, prosody,
say-as, sub,
s et voice.
L'élément s peut seulement contenir du texte à restituer et/ou les éléments suivants :
audio, break,
emphasis, mark,
phoneme, prosody,
say-as, sub et
voice.
L'élément say-as permet à l'auteur de fournir des informations à propos du type
de la structure textuelle qu'il contient et d'aider à la définition du niveau de détails
de la restitution du texte contenu.
Il est difficile de définir un ensemble complet des types de formats de texte à cause de la diversité des langues à considérer et
de la flexibilité innée des langues écrites. Le langage SSML définit uniquement l'élément say-as,
ses attributs et leurs buts. Il n'énumère pas les valeurs possibles des attributs. Le groupe de travail prévoit de produire un
document séparé afin de définir des valeurs normalisées ainsi que le comportement associé à ces valeurs. Les exemples donnés ici
ne font qu'illustrer l'utilisation de l'élément et ses attributs.
L'élément say-as a trois attributs : interpret-as,
format et detail ; l'attribut interpret-as est obligatoire,
les deux autres sont optionnels. Les valeurs légales de l'attribut format dépendent de la valeur de
l'attribut interpret-as.
L'élément say-as peut uniquement contenir du texte à restituer.
Les attributs interpret-as et format
L'attribut interpret-as indique le type de contenu de la structure textuelle contenue.
La définition du type de contenu aide le synthétiseur à distinguer et interpréter les structures textuelles
qui peuvent être restituées de différentes façons selon le type d'information prévu. En outre, l'attribut optionnel format
peut fournir d'autres indications sur le formatage précis du texte contenu des types de contenu dont les formats peuvent être ambigus.
Le synthétiseur doit interpréter les valeurs des attributs interpret-as et
format, s'ils sont définis, comme des indications de l'auteur du document balisé afin de guider
la normalisation de texte et la prononciation.
Dans tous les cas, le texte englobé par un élément say-as est censé être une
forme orthographique normalisée dans la langue du contexte courant. Un synthétiseur devrait être capable
de prendre en charge les formes orthographiques communes de la langue indiquée pour chaque type de contenu géré.
Si le processeur ne reconnaît pas la valeur de l'attribut interpret-as ou ne la gère pas,
il doit restituer le texte contenu comme si l'attribut interpret-as n'avait pas reçu de valeur.
Si le processeur ne reconnaît pas la valeur de l'attribut format ou ne la gère pas,
il doit restituer le texte contenu comme si l'attribut format n'avait pas reçu de valeur,
en utilisant la valeur indiquée par l'attribut interpret-as.
Si le contenu de l'élément say-as comprend un autre texte, parallèlement au contenu
dans le type indiqué par les attributs format et interpret-as, alors cet autre texte
doit être restitué. Le processeur peut restituer l'autre texte dans le type indiqué par l'attribut interpret-as
de l'élément où il apparaît.
Si le contenu de l'élément say-as ne comprend aucune partie dans le type indiqué
par l'attribut interpret-as (ou format), le processeur doit restituer le contenu comme si
l'attribut format n'était pas présent, ou bien comme si l'attribut interpret-as
n'était pas présent, ou bien comme si ni les attributs format ni interpret-as
n'étaient présents. Le processeur devrait également informer l'environnement de cette inadaptation.
L'indication du type de contenu ou du format n'affecte pas forcément la façon dont l'information est prononcée. Un
synthétiseur devrait prononcer le texte contenu de la façon dont un tel contenu est normalement produit
pour la langue.
L'attribut detail
L'attribut optionnel detail indique le niveau de détails à dire ou à restituer. Chaque valeur
de l'attribut detail doit restituer tout le contenu informationnel du texte contenu ; toutefois, on peut
utiliser des valeurs particulières de l'attribut detail pour restituer un contenu habituellement non informationnel
dans la composition courante mais dont la restitution peut être importante pour certaines raisons. Par exemple,
un synthétiseur restituera habituellement les signes de ponctuation par des changements appropriés
dans la prosodie. On peut fixer un niveau de détails supérieur pour que les signes de ponctuation soient dit explicitement, par exemple,
pour lire des codes de pièces de rechange ou des morceaux de programme.
L'attribut detail peut servir avec tous les types indiqués par l'attribut interpret-as.
Si l'attribut detail n'est pas indiqué, le niveau de détails produit par le synthétiseur
dépendra du contenu textuel et de la langue.
Si le processeur ne reconnaît pas la valeur de l'attribut detail ou ne la gère pas, alors il doit restituer
le texte contenu comme si l'attribut detail n'avait pas reçu de valeur.
L'élément phoneme donne une prononciation phonémique/phonétique du texte contenu.
L'élément phoneme peut être vide. Toutefois, on recommande qu'il contienne du
texte lisible par un humain pouvant être utilisé pour une restitution non sonore du document. Par exemple, le contenu peut être présenté
visuellement à des utilisateurs sourds.
L'attribut obligatoire ph indique la chaîne de phonème/phone.
Cet élément est conçu strictement pour les notations phonémiques et phonétiques ; il indique la prononciation d'un mot ou d'une
très petite phrase. La chaîne phonémique/phonétique ne subit aucune normalisation de texte
ni n'est traitée comme un atome à rechercher dans le lexique (cf. section 3.1.4), au contraire des valeurs
dans les éléments say-as et sub qui
peuvent passer par les deux. En bref, les chaînes phonémiques se composent de phonèmes, c'est-à-dire
d'unités de parole, dépendantes de la langue, et qui caractérisent en linguistique
des différences significatives dans la langue ; grosso modo, les phonèmes représentent tous les sons nécessaires pour distinguer
un mot d'un autre dans une langue donnée. Les chaînes phonétiques se composent de phones, c'est-à-dire d'unités de parole qui caractérisent
la façon (souffle,
claquement,
vocalisation, etc.) et le lieu de l'articulation (en avant, au milieu, en arrière, etc.)
dans le tractus de la voix humaine, etc., et qui sont donc indépendantes de la langue ;
les phones représentent des distinctions réalisées pour la production de la parole humaine.
L'attribut optionnel alphabet désigne l'alphabet phonémique/phonétique. Dans ce contexte, un alphabet se rapporte
à un ensemble de symboles représentant les sons d'une ou de plusieurs langues. Les seules valeurs valides de cet attribut sont
"ipa" (cf. le paragraphe suivant) et des chaînes définies par les vendeurs de la forme x-organisation
ou x-organisation-alphabet
. Par exemple, l'Association des industries électroniques et des technologies de l'information du Japon
(JEITA) [JEITA]
pourrait encourager l'utilisation d'un alphabet de phonèmes identifié par x-JEITA
ou x-JEITA-2000
[JEIDAALPHABET].
Les synthétiseurs devraient gérer la valeur "ipa" de l'attribut alphabet,
laquelle correspond aux représentations Unicode des caractères phonétiques développés par l'Association phonétique internationale
(API) [IPA]. Outre un ensemble complet de symboles
pour les voyelles et les consonnes, ce jeu de caractères comprend un délimiteur de syllabes, de nombreux diacritiques,
des symboles d'accentuation,
des symboles de tons lexicaux,
des signes d'intonation et plus.
Pour cet alphabet, les valeurs légales de l'attribut ph sont les chaînes de valeurs définies dans l'annexe 2
du manuel [IPAHNDBK]. On peut trouver des tableaux informatifs des correspondances API vers Unicode
dans [IPAUNICODE1] et [IPAUNICODE2]. Remarquez que les caractères API
ne sont pas tous disponibles dans Unicode. Pour un processeur prenant en charge cet alphabet :
- Il doit accepter la syntaxe de toutes les valeurs légales de l'attribut
ph ;
- À réception de codes API Unicode, il devrait produire une sortie dont on peut raisonnablement estimer qu'elle appartient
à la langue courante ;
- À réception d'autres codes, il produit une sortie entièrement à sa discrétion.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<phoneme alphabet="ipa" ph="təmei̥ɾou̥"> tomato </phoneme>
<!-- Voici un exemple de code API avec des entités de caractère -->
<!-- Puisque beaucoup de combinaisons plateforme/navigateur/éditeur de texte
n'effectuent pas un copier-coller correct du texte Unicode,
cet exemple utilise les versions d'entités masquées des caractères API.
Normalement, on utiliserait directement la représentation UTF-8
de ces symboles : "təmei̥ɾou̥". -->
</speak>
Il y a condition d'erreur si la valeur indiquée par l'attribut alphabet est inconnue,
ou si elle n'est pas applicable par le synthétiseur. Si l'attribut alphabet
n'est pas défini, le comportement dépend du processeur.
L'élément phoneme peut uniquement contenir du texte (aucun élément).
L'élément sub sert à indiquer que le texte dans l'attribut alias
remplace celui qu'il contient pour la prononciation. Un document peut ainsi contenir à la fois une forme parlée et une forme écrite.
L'attribut obligatoire alias indique la chaîne à prononcer à la place de la chaîne englobée.
Le processeur devrait effectuer une normalisation de texte de la valeur de
l'attribut alias.
L'élément sub peut uniquement contenir du texte (aucun élément).
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<sub alias="World Wide Web Consortium">W3C</sub>
<!-- World Wide Web Consortium -->
</speak>
3.2 La prosodie et le style
L'élément voice est utilisé en production pour demander le changement de la voix.
Les attributs sont les suivants :
-
xml:lang : attribut optionnel d'indication de langue ;
-
gender : attribut optionnel indiquant le genre de la voix voulu pour dire le texte contenu.
Les valeurs énumérées sont : "male", "female", "neutral" ;
-
age : attribut optionnel indiquant l'âge (depuis la naissance) de la voix souhaité pour dire le texte contenu.
Les valeurs admissibles sont de type xsd:nonNegativeInteger
[SCHEMA2 §3.3.20] ;
-
variant : attribut optionnel indiquant la variante des autres caractéristiques de la voix à utiliser pour dire
le texte contenu (par exemple, la seconde voix féminine ci-dessous). Les valeurs admissibles sont de type
xsd:positiveInteger
[SCHEMA2 §3.3.25] ;
-
name : attribut optionnel indiquant le nom de la voix, propre au processeur, pour dire le texte contenu.
La valeur peut être une liste de noms, séparés par des espaces et rangés en ordre de préférence décroissante.
Un nom ne peut donc pas contenir d'espace.
Bien que chaque attribut soit optionnel individuellement, il y a condition d'erreur si aucun attribut n'est
défini dans l'utilisation de l'élément voice.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<voice gender="female">Marie avait un petit agneau,</voice>
<!-- on demande maintenant une autre voix féminine -->
<voice gender="female" variant="2">
Sa toison était blanche comme neige.
</voice>
<!-- une sélection de voix propre au processeur -->
<voice name="Michel">Je veux être comme Michel.</voice>
</speak>
L'élément voice est couramment utilisé pour changer de langue. S'il n'y a aucune voix
disponible correspondant exactement aux attributs définis dans le document, ou si plusieurs voix correspondent aux critères,
l'algorithme de sélection de voix suivant doit être utilisé. L'algorithme est parfois incertain, auquel cas la sélection de la voix
peut dépendre du processeur. Approximativement, la priorité de l'attribut xml:lang
est la plus élevée, et les autres attributs ont une priorité équivalente mais inférieure. Voici l'algorithme complet :
- Si une voix est disponible pour la langue indiquée par l'attribut
xml:lang,
alors le synthétiseur doit l'utiliser. Si plusieurs voix de ce type sont disponibles,
alors le processeur devrait utiliser celle qui correspond le mieux aux valeurs indiquées par les attributs name,
variant, gender et age ;
- Si aucune voix n'est disponible pour la langue indiquée par l'attribut
xml:lang,
alors le processeur devrait sélectionner celle la plus proche de la langue demandée (par exemple, une variante ou un dialecte
de cette même langue). Si plusieurs voix de ce dernier type sont disponibles, alors le processeur devrait utiliser celle qui correspond
le mieux aux valeurs indiquées par les attributs name, variant, gender
et age ;
- Il y a condition d'erreur si le processeur reste indécis, en estimant qu'aucune voix ne suffit aux critères précédents.
Remarquez que l'on peut incorporer du texte dans une langue étrangère dans des cas simples (lorsqu'un changement de voix est superflu
ou indésirable). Cf. l'annexe F pour des exemples.
Les attributs de l'élément voice sont hérités en descendant l'arbre hiérarchique
du document, y compris par les éléments qui changent de langue.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<voice gender="female">
Une voix féminine ici.
<voice age="6">
Une voix de fillette ici.
<p xml:lang="ja">
<!-- Une voix féminine en japonais. -->
</p>
</voice>
</voice>
</speak>
Les changements relatifs des paramètres prosodiques devraient se reporter d'une voix à l'autre. Par contre, puisqu'elles représentent
des personnalités différentes, les diverses voix n'ont pas les mêmes valeurs naturelles par défaut en ce qui concerne la hauteur tonale,
le rythme de la parole, etc., de sorte que les valeurs absolues de ces paramètre prosodiques peuvent varier au cours du changement de voix.
La qualité de la sortie sonore ou vocale pourra pâtir d'un changement de voix demandé au cours d'une phrase.
L'élément voice peut seulement contenir du texte à restituer et/ou les éléments suivants :
audio, break,
emphasis, mark,
p, phoneme,
prosody, say-as,
sub, s et
voice.
L'élément emphasis oblige à dire le texte contenu avec emphase
(on dit également mettre en exergue
ou accentuer).
Le synthétiseur détermine comment restituer l'emphase puisque sa nature diffère entre les langues, les dialectes
ou même les voix. Les attributs sont les suivants :
-
level : attribut optionnel indiquant la force de l'emphase à appliquer. Les valeurs définies sont :
"strong", "moderate", "none" et "reduced". Le niveau d'emphase par défaut vaut
"moderate". L'interprétation des niveaux "strong" et "moderate" dépend de la langue utilisée
(les langues indiquent une emphase en recourant à une combinaison possible de changement de tonalité, de changements de rythme,
d'augmentation du volume et d'autres différences acoustiques). Le niveau "reduced" représente en fait l'opposé de l'emphase.
Par exemple, si la valeur "reduced est appliqué au terme je vai
, il sera peut-être prononcé j'vai
.
On utilise le niveau "none" pour empêcher que le synthétiseur ne mette en exergue les mots qu'il
aurait normalement accentués. Les valeurs "none", "moderate" et "strong" représentent des
forces monotones non décroissantes.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
Voici une <emphasis> grosse </emphasis> voiture !
C'est un compte bancaire <emphasis level="strong"> énorme </emphasis> !
</speak>
L'élément emphasis peut seulement contenir du texte à restituer et/ou les éléments suivants :
audio, break,
emphasis, mark,
phoneme, prosody,
say-as, sub,
voice.
L'élément vide break contrôle les pauses ou
d'autres limites prosodiques entre les mots.
L'utilisation de l'élément break entre deux mots est optionnelle.
S'il n'est pas présent entre les mots, le synthétiseur devra déterminer automatiquement une interruption
d'après le contexte linguistique. En pratique, l'élément break est utilisé le plus souvent
pour neutraliser le comportement automatique habituel du synthétiseur. Les attributs de cet élément sont les suivants :
-
strength : attribut optionnel ayant l'une des valeurs "none", "x-weak",
"weak", "medium" (valeur par défaut), "strong" ou "x-strong". Cet attribut sert à indiquer
la force de l'interruption prosodique dans la sortie vocale. La valeur "none"
indique de ne pas produire de limite d'interruption prosodique, et elle peut servir pour empêcher une interruption prosodique
que le processeur aurait produite sinon. Les autres valeurs indiquent des
forces d'interruption monotones non décroissantes
(conceptuellement croissantes) entre les mots. Les plus fortes interruptions s'accompagnent habituellement de pauses.
Les intitulés "x-weak" et "x-strong" sont associés respectivement à
extra weak
et extra strong
.
-
time : attribut optionnel indiquant la durée de la pause à insérer en sortie, exprimée en secondes
ou millisecondes. Elle suit le format de valeur temporelle défini dans la spécification des feuilles de style en cascade niveau 2
[CSS2], par exemple, "250ms" ou "3s".
L'attribut strength sert à indiquer la force prosodique de l'interruption. Par exemple,
les interruptions entre paragraphes sont habituellement plus fortes que celles entre les mots dans une phrase.
Le synthétiseur peut insérer une pause pour interpréter une interruption prosodique.
On peut également insérer une pause de longueur définie avec l'attribut time.
Si l'élément break est utilisé sans attribut strength
ni attribut time, le processeur produira une interruption de force prosodique supérieure
à celle qu'il aurait utilisée en absence d'élément break.
Si les deux attributs strength et time sont présents, le processeur insèrera
une interruption dont la durée sera celle indiquée par l'attribut time, plus d'autres changements prosodiques
en sortie selon la valeur de l'attribut strength.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
Respirez à fond <break/>
puis continuez.
Tapez 1 ou attendez la tonalité. <break time="3s"/>
Vous n'avez rien dit ! <break strength="weak"/> Veuillez répéter.
</speak>
L'élément prosody permet de maîtriser la hauteur tonale, le rythme et le volume sonore
de la sortie vocale. Tous les attributs suivants sont optionnels :
-
pitch : la hauteur tonale de référence du texte contenu. Bien que l'interprétation de la
hauteur tonale de référence
varie d'un synthétiseur à l'autre, l'augmentation (ou la diminution) de cette valeur augmentera (ou diminuera)
normalement la tonalité approximative de la sortie. Les valeurs légales sont les suivantes : un nombre
suivi immédiatement de la chaîne Hz
, un changement relatif, ou les valeurs "x-low",
"low", "medium", "high", "x-high" ou "default". Les étiquettes de
"x-low" à "x-high" représentent une séquence de niveaux de tonalité monotones non décroissants.
-
contour : fixe le profil tonal réel
du texte contenu. Le format est défini dans la section Le profil tonal ci-dessous.
-
range : la gamme tonale (variabilité) du texte contenu.
Bien que la signification exacte de la gamme tonale
varie d'un synthétiseur à l'autre, l'augmentation (ou la diminution)
de cette valeur augmentera (ou diminuera) normalement l'amplitude dynamique de la tonalité de sortie. Les valeurs légales sont les suivantes :
un nombre suivi immédiatement par la chaîne Hz
, un changement relatif,
ou les valeurs "x-low", "low", "medium", "high", "x-high" ou "default".
Les étiquettes de "x-low" à "x-high" représentent une séquence de gammes tonales monotones non décroissantes.
-
rate : un changement dans le rythme de la parole du texte contenu. Les valeurs légales sont les suivantes :
un changement relatif, ou les valeurs "x-slow", "slow", "medium",
"fast", "x-fast" ou "default". Les étiquettes de "x-slow" à "x-fast"
représentent une séquence de rythmes de parole monotones non décroissants. Si on utilise un nombre pour définir
un changement relatif, il agit comme multiplificateur du rythme par défaut. Par exemple, une valeur
de "1" ne produit aucun changement dans le rythme de la parole, une valeur de "2" signifie un rythme multiplié par deux
et une valeur de "0.5" signifie un rythme divisé par deux. Le rythme par defaut d'une voix dépend de la langue et du dialecte,
et de la personnalité de la voix. Le rythme par défaut d'une voix devrait être tel que celui perçu comme un rythme de parole normal
pour la voix dans une lecture du texte à voix haute. Puisque les voix sont spécifiques au processeur, le rythme par défaut le sera également.
-
duration : une valeur en secondes ou millisecondes indiquant la durée de lecture souhaitée du contenu de l'élément.
Elle obéit au format de valeur temporelle défini dans la spécification des feuilles de style en cascade niveau 2
[CSS2], par exemple, "250ms" ou "3s".
-
volume : le volume sonore du texte contenu dans l'intervalle 0.0 à 100.0 (plus la valeur est élevée plus le volume croît,
et la valeur zéro équivaut à "silent"). Les valeurs légales sont les suivantes :
un nombre, un changement relatif, ou les valeurs "silent",
"x-soft", "soft", "medium", "loud", "x-loud" ou "default".
L'échelle de volume est linéaire. La valeur par défaut est "100.0". Les étiquettes de "silent" à "x-loud"
représentent une séquence de niveaux sonores monotones non décroissants.
Bien que chaque attribut soit optionnel pris individuellement, il y a condition d'erreur si aucun n'est défini
avec l'élément prosody. Les valeurs d'attributs intitulées
x-quelque chose
sont associées à extra quelque chose
. Toutes les unités (Hz
, st
, etc.)
sont sensibles à la casse. Remarquez également que les niveaux de tonalité habituels et les gammes tonales normalisées peuvent varier
significativement selon la langue, tout comme les significations des valeurs étiquetées des cibles et gammes de tonalité.
Un nombre est une valeur en virgule flottante positive simple sans exponentielle. Les formats des valeurs légales sont les suivants :
n
, n.
, .n
et n.n
, où n
représente une séquence
composée d'un ou plusieurs chiffres.
Pour les attributs précédents, on peut définir les changements relatifs en tant que :
- Pourcentage (un nombre, précédé en option d'un signe plus
+
ou moins -
,
suivi d'un signe pourcentage %
), par exemple 3%
, +15.2%
ou -8.0%
, ou ;
- Nombre relatif :
- Pour l'attribut
rate, les changements relatifs sont des nombres ;
- Pour l'attribut
volume, les changements relatifs sont des nombres
précédés d'un signe plus +
ou moins -
, par exemple, +10
ou -5.5
;
- Pour les attributs
pitch et range, les changements relatifs peuvent s'exprimer
en demi-tons (un nombre précédé d'un signe plus +
ou moins -
suivi de la chaîne st
), ou en Hertz (un nombre précédé d'un signe plus +
ou moins -
suivi de la chaîne Hz
), par exemple, +0.5st
, +5st
, -2st
,
+10Hz
, -5.5Hz
. Un demi-ton correspond à la moitié d'un ton (un demi-pas) sur l'échelle diatonique standard.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
Le prix de XYZ est de <prosody rate="-10%">45€</prosody>
</speak>
Le profil tonal est défini par un ensemble de cibles, séparées par des espaces,
repérées chronologiquement dans la sortie vocale. L'algorithme d'interpolation entre les cibles est spécifique au processeur.
Dans chaque couple de la forme (repère chronologique, cible), la première valeur correspond à un pourcentage
de la durée du texte contenu (un nombre suivi d'un signe pourcentage %
), et la seconde à la valeur de
l'attribut pitch (un nombre suivi de la chaîne Hz
,
ou un changement relatif, ou une valeur prédéfinie).
Les valeurs de repère chronologique hors de l'intervalle 0% à 100% sont ignorées. Si aucune valeur de tonalité n'est définie pour 0% ou 100%,
alors la cible de tonalité la plus proche est copiée. Toutes les valeurs de tonalité relatives le sont par rapport à la valeur de
l'attribut pitch juste avant le texte contenu.
<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="fr">
<prosody contour="(0%,+20Hz) (10%,+30%) (40%,+10Hz)">
bonjour
</prosody>
</speak>
L'attribut duration est prioritaire sur l'attribut rate, et
l'attribut contour est prioritaire sur les attributs pitch et range.
La valeur par défaut de tous les attributs prosodiques ne change pas. Par exemple, un attribut rate omis
signifie que le rythme reste le même tant à l'intérieur de l'élément qu'en dehors.
L'élément prosody peut seulement contenir du texte à restituer et/ou les attributs suivants :
audio, break,
emphasis, mark,
p, phoneme,
prosody, say-as,
sub, s,
voice.
Les limitations
Toutes les valeurs des attributs prosodiques sont indicatives. Si un synthétiseur n'est pas capable de restituer
exactement le document comme indiqué (par exemple, essayant de fixer la tonalité à 1MHz, ou le rythme de la parole à un million de mots par
minute), il doit s'efforcer de poursuivre le traitement en imposant une limite ou un substitut pour la valeur indiquée non gérée,
et il peut informer l'environnement hôte du franchissement de ces limites.
Dans certains cas, le synthétiseur peut décider d'ignorer un balisage prosodique donné s'il détermine,
par exemple, que la valeur indiquée est redondante, impropre ou erronée. En particulier,
les systèmes de synthèse vocale par concaténation
utilisant des unités acoustiques de grande dimension peuvent rejeter les éléments de balisage agissant sur la prosodie qui seraient
redondants avec la prosodie d'une ou de plusieurs unités acoustique, ou sinon qui dégraderaient la qualité de la parole.
3.3 Les autres éléments
L'élément audio permet d'insérer des fichiers sons enregistrés
(cf. l'annexe A pour les formats obligatoires) et d'au
