Source: http://www.vxmlitalia.com/ssml.html
Timestamp: 2016-09-28 06:47:46+00:00

Document:
VoiceXML Italian User Group - W3C Recommendation "Speech Synthesis Markup Language (SSML)" Versione 1.0 (traduzione in lingua italiana)
Questo documento e' una traduzione in lingua italiana della Raccomandazione W3C del 7 Settembre 2004 "Speech Synthesis Markup Language (SSML) Version 1.0". La traduzione e' stata completata il giorno 2 Marzo 2006.
L'URI di questo documento e'
/ssml.html
L'URI del documento originale in lingua inglese e'
L'URI della versione inglese piu' recente di questa Raccomandazione e'
L' unica versione normativa e' l'originale inglese. La presente traduzione in italiano non puo' essere considerata normativa in alcuna sua parte. Essa ha scopi puramente informativi per il lettore italiano e non e' un documento ufficiale del W3C.Per informazioni sul copyright si vedano le note poste alla fine del sommario.
La traduzione e' stata effettuata da Simone Pascarosa <info@vxmlitalia.com>.
Questo documento puo' contenere errori di traduzione. Qualsiasi errore riscontrato nelle seguenti pagine comunicato all'autore della traduzione e al VoiceXML Italian User Group verra' nel piu' breve tempo controllato e corretto.
Speech Synthesis Markup Language (SSML) Versione 1.0
W3C Recommendation 7 Settembre 2004
Si faccia riferimento all'errata
per questo documento, che può includere alcune correzioni normative.
Il Gruppo di Lavoro sul Voice Browser (il browser vocale) ha cercato di sviluppare degli standard per permettere l'accesso al Web attraverso l'interazione vocale. Lo Speech Synthesis Markup Language è uno di questi standard ed è progettato per fornire un linguaggio di marcatura ricco e basato sull'XML che assista la generazione di discorsi sintetizzati per il Web e per altre applicazioni. Il ruolo essenziale del linguaggio di marcatura è quello di fornire, ai creatori di contenuti di sintesi vocale, un metodo standard di controllare i vari aspetti del discorso come la pronuncia, il volume, il tono, il ritmo ecc. su piattaforme di sintesi diverse.
Questa sezione descrive lo stato di questo documento al momento della sua pubblicazione. Altri documenti possono sostituire questo. Si può trovare una lista delle pubblicazioni odierne del W3C e delle ultime revisioni dei suoi rapporti tecnici sull'indice dei rapporti tecnici del W3C presso http://www.w3.org/TR/.
Questo documento contiene le specifiche dello Speech Synthesis Markup Language (SSML) 1.0 ed è una W3C Recommendation. È stato prodotto come parte della Voice Browser Activity.
Gli autori di questo documento partecipano al gruppo di lavoro sul Voice
Browser (solo per membri del W3C).
Per maggiori informazioni si legga la Voice Browser FAQ.
Questo è un documento stabile ed è stato approvato dai membri del W3C e dai partecipanti al gruppo di lavoro sul Voice Browser.
Il design del SSML 1.0 è stato completamente rivisto (si veda la
disposition of comments) e soddisfa i requisiti tecnici del gruppo di lavoro.
Un elenco delle implementazioni è incluso nel SSML 1.0 Implementation
Report, insieme ai test associati.
I commenti sono benvenuti su www-voice@w3.org (archivio).
Si vedano le linee guida sull'uso dell'archivio e delle mailing list del W3C.
0. Tabella dei contenuti
1. Introduzione 1.1 Criteri di Design
1.2 Passaggi del Processo di Sintesi Vocale
1.3 Generazione di documenti, Applicazioni e Contesti
1.4 Comportamento dell'output SSML su piattaforme diverse
2.Documenti SSML 2.1 Forma del Documento
2.2 Conformità 2.2.1 Frammenti di Speech Synthesis Markup Language Conformi
2.2.2 Documenti Speech Synthesis Markup Language Conformi
2.2.3 Usare SSML con altri Namespace
2.2.4 Sintetizzatori Speech Synthesis Markup Language Conformi
2.2.5 User Agent Conforme
2.3 Integrazione con altri Linguaggi di Marcatura 2.3.1 SMIL
2.4 Ricerca e Gestione di Documenti SSML
3. Elementi ed Attributi 3.1 Struttura del Documento, Elaborazione del Testo e Pronuncia 3.1.1 Elemento radice "speak"
3.1.2 Lingua: Attributo "xml:lang"
3.1.3 URI di Base: Attributo "xml:base"
3.1.4 Lessico di Pronuncia: Elemento "lexicon"
3.1.5 Elemento "meta" 3.1.6 Elemento "metadata"
3.1.7 Struttura del Testo: Elementi "p" e "s"
3.1.8 Elemento "say-as"
3.1.9 Elemento "phoneme"
3.1.10 Elemento"sub"
3.2 Prosodia e Stile 3.2.1 Elemento "voice"
3.2.2 Elemento "emphasis"
3.2.3 Elemento "break"
3.2.4 Elemento "prosody"
3.3 Altri Elementi 3.3.1 Elemento "audio"
3.3.2 Elemento "mark"
3.3.3 Elemento "desc"
Appendix A. Formati di File Audio (normativo)
Appendix B. Internazionalizzazione (normativo)
Appendix C. MIME Types e Suffissi di File (normativo)
Appendix D. Schema per lo Speech Synthesis Markup Language (normativo)
Appendix E. DTD per lo Speech Synthesis Markup Language (informativo)
Appendix F. Esempi di SSML (informativo)
Appendix G. Elenco delle modifiche dalla Candidate Recommendation (informativo)
Questa specifica del W3C è conosciuta come Speech Synthesis Markup Language (SSML) ed è basata sulle specifiche JSGF e/o JSML, che sono di proprietà di Sun Microsystems, Inc., California, U.S.A. La specifica JSML si trova su [JSML].
L'SSML è parte di un più vasto insieme di specifiche di marcatura per browser vocali sviluppate dal W3C in modo apertp. È progettato per fornire un linguaggio di marcatura ricco e basato sull'XML che assista la generazione di discorsi sintetizzati per il Web e per altre applicazioni. Il ruolo essenziale del linguaggio di marcatura è quello di fornire, ai creatori di contenuti sintetizzati, un modo standard di controllare i vari aspetti del discorso come la pronuncia, il volume, il tono, il ritmo ecc. su piattaforme di sintesi diverse. Un progetto simile di creazione di un sistema standard per la marcatura di testi è SABLE [SABLE], che tenta di integrare diversi linguaggi, basati sull'XML, per la sintesi vocale in uno solo. L'esperienza portata avanti da SABLE è stata usata come principale punto di partenza per la definizione dei Requisiti dello Speech Synthesis Markup per Linguaggi di Marcatura Vocale [REQS]. Ad oggi, SABLE non ha avuti ulteriori sviluppi.
L'uso a cui è destinato l'SSML è quello di migliorare la qualità dei contenuti sintetizzati. Diversi elementi di marcatura influenzano i passaggi del processo di sintesi (si veda la Sezione 1.2). Il sorgente può essere prodotto sia automaticamente, per esempio con XSLT o CSS3 da un documento XHTML, o tramite la scrittura diretta da parte dell'utente. Le marcature devono essere presenti in un documento SSML completo (si veda la Sezione 2.2.2) o come parte di un frammento (si veda la Sezione 2.2.1) contenuto in un'altro linguaggio, sebbene non siano specificate interazioni con altri linguaggi come parte dell'SSML stesso. Molti degli elementi inclusi nell'SSML possono essere utilizzati dalla maggior parte dei creatori di contenuti; tuttavia alcune caratteristiche avanzate come i phoneme e la prosody (per esempio per il raffinamento della pronuncia) possono richiedere conoscenze specifiche.
1.1 Obiettivi di Design
I processi di design e di standardizzazione hanno seguito gli Speech Synthesis Markup Requirements per Linguaggi di Marcatura Vocale [REQS].
Ecco i criteri chiave seguiti per il design del linguaggio.
Consistenza: fornire controllo in previsione sull'output vocale su diverse piattaforme e su diverse implementazioni di sintesi vocale.
Interoperabilità: supportare l'uso combinato di altre specifiche W3C, incluse (ma non limitate a queste) VoiceXML, aural Cascading Style Sheets e SMIL.
Generalità: supportare un output vocale per una vasta gamma di applicazioni con contenuti vocali diversi.
Internazionalizzazione: permettere l'output vocale in un gran numero di lingue all'interno o tra documenti.
Generazione e Leggibilità: supportare la generazione automatica e la scrittura manuale di documenti. I documenti devono essere leggibili dall'uomo.
Implementabile: le specifiche devono essere implementabili con tecnologie esistenti e largamente disponibili, e il numero di caratteristiche opzionali deve essere minimo.
1.2 Passi del Processo di Sintesi Vocale
Un sistema Text-To-Speech (un sintetizzatore vocale) che supporta SSML deve provvedere a renderizzare un documento in un output vocale ed usare le informazioni contenute nel sorgente per produrre il documento proprio come specificato dall'autore.
Creazione del documento: Un documento di testo da dare in input al sintetizzatore vocale può essere creato automaticamente, tramite scrittura manuale, o attraverso una combinazione di queste forme. L'SSML definisce la forma del documento.
Elaborazione del documento: Vediamo quali sono i sei passi principali fatti dal sintetizzatore vocale per convertire un testo marcato in un output vocale generato automaticamente. Il linguaggio di marcatura è stato progettato per essere sufficientemente ricco e quindi per permettere un controllo su tutti i passaggi descritti qui sotto, in modo che l'autore del documento (umano o macchina) possa controllare l'output vocale finale. Sebbene ogni passo sia diviso in "supporto di marcatura" e "comportamento senza marcatura", il comportamento reale è di solito un mix dei due e varia in dipendenza dei tag usati. Il sintetizzatore ha la responsabilità di assicurare che il prodotto finale sia pronunciabile (e idealmente intelligibile). In generale la marcatura fornisce all'autore un modo per dare informazioni, come la metrica, al sintetizzatore; di solito queste informazioni riguardano quelle caratteristiche che il sintetizzatore non può acquisire da solo. Infine tocca al sintetizzatore determinare se e in che modo usare tali informazioni.
Analisi XML: Un analizzatore (parser) XML viene usato per estrarre l'albero del documento e il suo contenuto dal documento di testo in ingresso. La struttura, i tag e gli attributi ottenuti in questo passaggio influenzano tutti gli step successivi. I token (le parole) nell'SSML non possono essere suddivise dai tag. Un esempio in Inglese è "cup<break/>board"; il sintetizzatore vocale lo tratterà come due parole, "cup" e "board", invece di una sola con una pausa in mezzo. Spezzare un token in diversi token in questo modo influenza il modo in cui il sintetizzatore lo tratterà.
Analisi della Struttura: La struttura di un documento influenza il modo in cui il documento deve essere letto. Per esempio, ci sono modelli vocali associati a paragrafi e a frasi.
Supporto di marcatura: Gli elementi p e s in SSML definiscono esplicitamente la struttura del documento che influenza l'output vocale.
Comportamento senza marcatura: In documenti o parti di documento dove questi elementi non vengono utilizzati, il sintetizzatore vocale deve dedurre la struttura dall'analisi automatica del testo, di solito utilizzando la punteggiatura ed altri dati specifici della particolare lingua.
Normalizzazione del testo: Tutte le lingue scritte hanno costrutti speciali che richiedono una conversione della forma scritta (o forma ortografica) nella forma parlata. La normalizzazione del testo è un processo automatico del sintetizzatore vocale che espleta questa conversione. Per esempio, in Inglese, quando in un documento appare "$200", deve essere letto come "two hundred dollars" (duecento dollari). In modo simile, "1/2" può essere letto come "half", "January second", "February first", "one of two" e così via. Alla fine di questo passaggio il testo da leggere è stato convertito completamente in token. I dettagli esatti su cosa costituisce un token sono specifici della lingua scelta. In Inglese, i token sono di solito separati da spazi bianchi e tipicamente sono parole. Per lingue che si comportano diversamente con i token, il termine "token", in questa specifica, significa una appropriata unità confrontabile.
Supporto di marcatura: L'elemento say-as può essere usato nel documento in input per indicare esplicitamente la presenza e il tipo di questi costrutti e per risolvere le ambiguità. L'insieme di costrutti che possono essere marcati non è ancora stato definito ma può includere date, tempo, numeri, acronimi, somme di denaro ecc. Si noti che molti acronimi ed abbreviazioni possono essere gestiti dall'autore tramite la modifica diretta del testo oppure con l'uso dell'elemento sub, per esermpio "BBC" può essere scritto come "B B C" e "AAA" può essere scritto come "tripla A". Queste forme scritte di sostituzione dovrebbero essere pronunciate come una persona pronuncierebbe gli acronimi originali. In caso di testo in Giapponese, se si ha un sintetizzatore vocale che supporta sia Kanji che kana, si dovrebbe poter usare l'elemento sub per identificare se 今日は debba essere letto come きょうは ("kyou wa" = "oggi") o こんにちは ("konnichiwa" = "ciao").
Comportamento senza marcatura: Per testi non marcati con l'elemento say-as il sintetizzatore vocale dovrà fare un ragionevole sforzo per individuare e convertire automaticamente questi costrutti in una forma leggibile. Per colpa delle ambiguità (come nel suddetto esempio di "1/2") e della vasta gamma di possibili costrutti in tutte le lingue, questo processo può creare errori nell'output vocale e può accadere che diversi sintetizzatori renderizzino lo stesso documento in modi diversi.
Conversione Testo-Fonema: Una volta che il sintetizzatore vocale ha determinato l'insieme delle parole che devono essere lette, deve capire la pronuncia di ciasuna parola. La pronuncia delle parole può essere ben descritta come sequenza di fonemi, che sono unità di suono in una lingua che servono a distinguere una parola dalle altre. Ogni lingua (e a volte ogni variante dialettale o nazionale di una lingua) ha uno specifico insieme di fonemi: per esempio, la maggior parte dei dialetti di Inglese Americano hanno circa 45 fonemi, l'Hawaiano ha tra 12 e 18 fonemi (dipende dall'interlocutore), alcune lingue ne hanno più di 100! Questa conversione è resa ancora più complessa da alcuni aspetti. Il primo riguarda le differenze che esistono tra la forma scritta e parlata di una lingua, e queste differenze possono portare ad indeterminatezza o ambiguità nella pronuncia delle parole scritte. Per esempio, confrontate con le forme scritte, le parole in Ebraico e Arabo vengono spesso scritte senza vocali, oppure vengono specificate poche vocali. In molte lingue la stessa parola scritta può essere letta in modi diversi. Per esempio, in Inglese, "read" può essere letto come "reed" (come nella frase "I will read the book") o "red" (come nella frase "I have read the book"). Sia un lettore umano che un sintetizzatore vocale possono pronunciare queste parole in modo corretto nel contesto, ma hanno difficoltà senza il contesto (si veda "Comportamento senza marcatura" qui sotto). Un'altro aspetto è la gestione delle parole con pronuncia o spelling non standard. Per esempio, un sintetizzatore vocale Inglese avrà spesso problemi nel determinare come pronunciare alcuni nomi di origine non Inglese, per esempio "Caius College" (che si legge "keys college") e President Tito (che si pronuncia "sutto"), il presidente della Repubblica di Kiribati (che si pronuncia "kiribass").
Supporto di marcatura: L'elemento phoneme permette di fornire una sequenza fonematica per ogni parola o sequenza di parole. Questa caratteristica permette ai creatori di contenuti di controllare esplicitamente la pronuncia. L'elemento say-as può essere anche usato per indicare che un certo testo è un nome proprio sul quale il sintetizzatore vocale può applicare particolari regole per determinarne la pronuncia. L'elemento lexicon può essere usato per fare riferimento a definizioni di pronuncia esterne. Questi elementi possono essere particolarmente utili per gli acronimi e le abbreviazioni sui quali il sintetizzatore è incapace di risolvere la pronuncia tramite la normalizzazione del testo e che non sono risolvibili attraverso la sostituzione del testo o con l'elemento sub (si veda il paragrafo 3, qui sopra).
Comportamento senza marcatura: In assenza di un elemento phoneme, il sintetizzatore vocale deve applicare delle procedure automatiche per determinare la pronuncia. Per raggiungere il suo scopo, di solito il sintetizzatore fa uso di un dizionario delle pronunce (dipendente dalla lingua) nel quale ricercare le parole e applicando varie regole per determinare le altre pronunce.
I sintetizzatori vocali sono progettati per operare conversioni testo-fonema così che la maggior parte delle parole dei documenti possano essere gestite automaticamente. Come alternativa ad affidarsi al sintetizzatore, gli autori possono scegliere di operare alcune conversioni loro stessi, prima della codifica in SSML. Le parole con pronuncia indeterminata o ambigua possono essere rimpiazzate con parole senza pronuncia ambigua; per esempio, nel caso di "read", potremmo scrivere "I will reed the book". Gli autori devono però stare attenti, comunque, perché il documento SSML può non essere ideale per la visualizzazione.
Analisi della prosodia: La prosodia è l'insieme delle caratteristiche dell'output vocale che include tonalità (detta anche intonazione o melodia), tempo (o ritmo), pause, frequenza vocale, enfasi sulle parole ed altre caratteristiche. Produrre una prosodia simile a quella umana è importante per far sembrare il parlato naturale e per comunicare correttamente il significato del parlato. Supporto di marcatura: Gli elementi emphasis, break e prosody possono essere usati congiuntamente dagli autori di documenti per guidare il sintetizzatore vocale nella generazione di un discorso con un appropriata prosodia.
Comportamento senza marcatura: In assenza di questi elementi, i sintetizzatori vocali sono maestri (ma non perfetti) nella generazione automatica di un'adeguata prosodia. Ciò viene realizzato tramite l'analisi della struttura del documento, della sintassi delle frasi ed altri informazioni che possono essere dedotte dal testo in input.
Anche se la maggior parte degli elementi in SSML possono essere considerati di alto livello in ciò che fanno sia sul testo che deve essere letto che sulla descrizione dello stile, gli elementi break e prosody appena menzionati lavorano ad un livello successivo del processo e per questo devono coesistere con l'elemento emphasis e con le caratteristiche di determinazione della prosodia proprie del sintetizzatore. A meno che non sia specificato nella specifica sezione, i dettagli sull'interazione tra il processo di determinazione del sintetizzatore e le informazioni fornite dall'autore del documento, a questo livello, sono specifici del sintetizzatore. Gli autori sono incoraggiati a non mischiare arbitrariamente questi due livelli di controllo.
Riproduzione della Waveform: Le informazioni sui fonemi e sulla metrica vengono usate dal sintetizzatore vocale nella renderizzazione della waveform. Ci sono molti approcci per questa operazione che possono essere ritenute variazioni specifiche del sintetizzatore.
Supporto di marcatura: L'elemento voice permette ai creatori di documenti di usare una particolare voce e di specificare certe qualità della voce (ad esempio, una voce maschile giovane). L'elemento audio permette l'inserimento di dati audio registrati nel flusso in uscita.
Ci sono molti generi di creatori di documenti che producono testi marcati che devono essere letti dal sintetizzatore vocale. Non tutti i creatori di documenti (sia umani che macchine) hanno accesso alle informazioni che vengono usate negli elementi o nelle varie fasi descritte nella sezione precedente. Seguono alcuni dei casi più comuni.
Il creatore del documento non ha accesso alle informazioni per marcare il testo. Tutte le fasi di sintesi del sintetizzatore vocale devono essere svolte completamente in modo automatico sul testo grezzo. Il documento richiede solo l'elemento contenitore speak per indicare il testo che deve essere letto.
Quando il testo marcato è generato via software, il creatore può avere conoscenze specifiche sulla struttura e/o su costrutti di testo speciali, in parte o su tutto il documento. Per esempio, un client di posta può marcare le diciture di ora e data dei messaggi. Questo tipo di applicazioni possono usare elementi che influenzano la struttura, la normalizzazione del testo, la prosodia e magari la conversione testo-fonema.
Alcuni creatori di documenti compiono sforzi considerevoli per marcare più dettagli possibili del documento per assicurare una discreta qualità del parlato su diverse piattaforme e per specificare più precisamente la qualità dell'output. In questi casi, il testo marcato può usare alcuni o tutti gli elementi disponibili per controllare più strettamente l'output vocale. Per esempio, i messaggi generati dai servizi telefonici e i browser vocali possono essere messi a punto per massimizzare l'efficenza di tutto il sistema.
I creatori di documenti più smaliziati possono saltare la marcatura d'alto livello (struttura, normalizzazione del testo, conversione testo-fonema e analisi della prosodia) e produrre una marcatura di sintesi vocale di basso livello per frammenti di documento o per documenti interi. Di solito per fare un'operazione del genere c'è bisogno di strumenti per generare sequenze di fonemi, con informazioni su tonalità e frequenza. Per esempio, le applicazioni che fanno la "sintesi di copia" o la "copiatura della prosodia" provano ad emulare la dialettica umana copiando alcune proprietà dalle registrazioni.
Seguono alcuni esempi di architetture e progetti che possono generare documenti marcati per la sintesi vocali. Lo scopo del linguaggio è quello di facilitare ciascuno di questi approcci.
Linguaggi di Dialogo: È richiesta la possibilità di includere documenti SSML nei documenti di dialogo del Voice Browser Working Group.
Interoperabilità con aural CSS (ACSS): Ogni processore HTML che è compatibile con aural CSS può produrre documenti SSML. L'ACSS viene trattato nella Sezione 19 della Specifica su Cascading Style Sheets, level 2 (CSS2) [CSS2 §19]. Questo uso della sintesi vocale facilita l'accessibilità ai contenuti HTML e XHTML preesistenti.
Elaborazione di fogli di stile specifici per applicazione: Come già accennato, ci sono tipi di applicazione che conoscono il testo che deve essere letto, e che possono essere incorporate nella marcatura di sintesi vocale per migliorare il rendering del documento. In molti casi, ci si può aspettare che l'applicazione usi fogli di stile per operare trasformazioni su documenti XML esistenti in SSML. Ciò equivale ad usare ACSS con HTML ed ancora una volta SSML è la rappresentazione risultante che deve essere passata al sintetizzatore vocale. In questa ottica, l'SSML può essere visto come un contenitore delle capacità dell'ACSS [CSS2§19], ad eccezione dell'audio spaziale.
L'SSML fornisce un metodo standard per specificare a grandi linee le proprietà dei contenuti sintetizzati come la pronuncia, il volume, il tono, la frequenza, ecc. Le specifiche esatte del comportamento dell'output vocale su diversi sintetizzatori, esulano comunque lo scopo di questo documento.
A meno che non sai diversamente specificato, i valori di marcatura sono mere indicazioni lontane dall'essere assolute. Per esempio, è possibile che un autore indichi esplicitamente la durata di un segmento di testo e indichi inoltre la durata per un pezzo di quel segmento. Se le due durate producono un segmento di testo che il sintetizzatore vocale non può ragionevolmente renderizzare, allora il sintetizzatore ha la possibilità di modificare le durate secondo le sue necessità per produrre l'output vocale.
Termini necessari
Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DOVRÀ", "NON DOVRÀ", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "PUÒ", e "OPZIONALE" in questo documento devono essere interpretate come descritto in [RFC2119]. Comunque, per leggibilità, queste parole non appaiono con lettere tutte maiuscole in questa specifica.
Un sintetizzatore vocale conforme può o deve (dipende dal verbo modale usato nelle frase) comportarsi come descritto; se lo fa, deve fornire all'utente un metodo per abilitare o disabilitare la funzione descritta.
I risultati sono indefiniti. Un sintetizzatore vocale conforme può rilevare e riportare un errore e può anche risolvere il problema.
Un tipo di media (definito in [RFC2045] e [RFC2046]) specifica la natura di una risorsa collegata. I tipi di media non sono sensibili alle maiuscole. Una lista di tipi di media registrati è disponibile per lo scaricamento [TIPI]. Si veda l'Appendice C per maggiori informazioni sui tipi di media dell'SSML.
Il processo di generazione automatica dell'output vocale da dati in input che possono contenere testo, testo marcato o oggetti binari.
Un sistema Text-To-Speech che accetta documenti SSML in input e li renderizza come output vocale.
Il processo di generazione automatica dell'output vocale da testo o da un input testuale scritto.
URI: Identificatore Uniforme di Risorse
Un URI è una sintassi unificata per l'espressione di nomi e indirizzi di oggetti sulla rete come viene fatto nel World Wide Web. Un URI è definito come qualsiasi primitiva legittima anyURI come definito nel XML Schema Parte 2: Tipi di Dato [SCHEMA2 §3.2.17]. Per motivi puramente informativi, [RFC2396] e [RFC2732] possono essere utili per capire la struttura, il formato e l'uso degli URI. Ogni riferimento URI relativo deve essere risolto seguendo le regole descritte nella Sezione 3.1.3.1. In questa specifica, gli URI sono forniti come attributi di elementi, per esempio negli elementi audio e lexicon.
Un dispositivo che interpreta un linguaggio di marcatura (vocale) e che è capace di generare un'output vocale e/o interpretare un input vocale, e possibilmente fornire altre modalità di input/output.
2. Documenti SSML
2.1 Forma del Documento
Un documento in Speech Synthesis Markup Language isolato legittimo deve avere un XML Prolog legittimo [XML §2.8]. Se presente, il DOCTYPE opzionale deve suonare come il seguente:
Il prologo XML è seguito dall'elemento radice speak. Si veda la Sezione 3.1.1 per maggiori dettagli su questo elemento.
L'elemento speak indica il namespace SSML. Viene fatto dichiarando un attributo xmlns o un attributo con il prefisso "xmlns". Si veda [XMLNS §2] per ulteriori informazioni. Da notare che quando l'attributo xmlns viene usato da solo, imposta il namespace di default per l'elemento su cui appare e per gli elementi figli. Il namespace per l'SSML deve essere http://www.w3.org/2001/10/synthesis.
È raccomandato che l'elemento speak indichi anche la locazione dello Schema SSML (si veda l'Appendice D) attraverso l'attributo xsi:schemaLocation da [SCHEMA1 §2.6.3]. Beché non sia richiesta questa indicazione, per incoraggiarne l'uso questo documento la specifica su tutti i suoi esempi.
I seguenti sono due esempi di intestazioni SSML legittime:
Gli elementi meta, metadata e lexicon devono trovarsi prima di tutti gli altri elementi e prima del testo, e trovarsi all'interno dell'elemento radice speak. Non ci sono altri vincoli di ordine sugli elementi di questa specifica.
2.2. Conformità
2.2.1 Frammenti di Speech Synthesis Markup Language Conformi
Un frammento di documento è un Frammento di Speech Synthesis Markup Language Conforme se:
è conforme ai criteri su Documenti Speech Synthesis Markup Language Conformi: con l'eccezione di xml:lang e xml:base , tutti gli elementi e gli attributi con namespace non di sintesi vocale e tutti gli attributi xmlns che fanno riferimento ad elementi con namespace non di sintesi vocale che verranno rimossi dal documento,
e, se l'elemento speak non indica già il namespace di sintesi usando l'attributo xmlns, allora viene aggiunto all'elemento xmlns="http://www.w3.org/2001/10/synthesis".
Un documento è un Documento Speech Synthesis Markup Language Conforme se rispetta entrambe le seguenti condizioni:
è un documento XML ben formattato [XML §2.1] conforme ai Namespace in XML [XMLNS].
è un documento XML valido [XML §2.8] che rispetta le specifiche descritte in questo documento (Speech Synthesis Markup Language Specification) inclusi i limiti espressi nello Schema (si veda l'Appendice D) e che ha un Prologo XML e un elemento radice speak come specificato nella Sezione 2.1.
La specifica SSML e questi criteri di conformità non specificano limiti di dimensione su tutti gli aspetti dei documenti. Non ci sono valori massimi sui numeri di elementi, sul numero di caratteri dati, o sul numero di caratteri per i valori degli attributi.
Il namespace di sintesi vocale può essere usato con altri namespace XML come specificato sulla XML Recommendation riguardo i namespace [XMLNS]. Progetti futuri del W3C creeranno sistemi per specificare la conformità di documenti che fanno uso di diversi namespace.
Un sintetizzatore Speech Synthesis Markup Language è un programma che riesce ad analizzare ed elaborare Documenti Speech Synthesis Markup Language Conformi.
In un Sintetizzatore Speech Synthesis Markup Language Conforme, il parser XML deve essere capace di analizzare ed elaborare tutti i costrutti XML definiti dall'XML 1.0 [XML] e i Namespace dell'XML [XMLNS]. Non è richiesto che il parser XML operi la validazione di un documento SSML con il suo schema o DTD; ciò implica che durante l'elaborazione di un documento SSML è lasciata opzionale la possibilità di applicare o espandere riferimenti ad entità esterne definite in un DTD esterno.
Un Sintetizzatore Speech Synthesis Markup Language Conforme deve conoscere ed applicare correttamente la semantica di ogni elemento di marcatura come descritto da questo documento.
Un Sintetizzatore Speech Synthesis Markup Language Conforme deve rispondere ai seguenti requisiti per gestire i linguaggi naturali (umani):
È richiesto che un Sintetizzatore Speech Synthesis Markup Language Conforme analizzi con successo tutte le dichiarazioni del linguaggio naturale legittime.
Un Sintetizzatore Speech Synthesis Markup Language Conforme può essere capace di applicare la semantica dei linguaggi di marcatura che fanno riferimento a più di un linguaggio naturale. Quando un sintetizzatore è capace di supportare tutti i linguaggi naturali dell'insieme ma non può gestirli contemporaneamente, dovrebbe informare l'ambiente d'esecuzione. Quando l'insieme include uno o più linguaggi naturali che non sono supportati dal sintetizzatore, quest'ultimo dovrebbe informare l'ambiente d'esecuzione.
Un Sintetizzatore Speech Synthesis Markup Language Conforme può implementare i linguaggi naturali con una sostituzione approssimativa conformemente a caratteristiche specifiche documentate del sintetizzatore. Per esempio, un sintetizzatore vocale di Inglese Americano potrebbe elaborare un input in Inglese Britannico.
Quando un Sintetizzatore Speech Synthesis Markup Language Conforme incontra elementi o attributi, eccetto xml:lang e xml:base , in un namespace non di sintesi vocale, può:
ignorare gli elementi e/o attributi non standard
o, elaborare gli elementi e/o attributi non standard
o, rifiutare il documento contenente quegli elementi e/o attributi
Non esistono, comunque, dei requisiti di conformità rispetto alle performance del Sintetizzatore Speech Synthesis Markup Language. Per esempio, non sono stati stabiliti parametri riguardo l'accuratezza, la velocità ed altre caratteristiche della voce prodotta dal sintetizzatore. Non esistono regole riguardo la lunghezza dell'input che un Sintetizzatore Speech Synthesis Markup Language deve rispettare.
Uno User Agent Conforme è un Sintetizzatore Speech Synthesis Markup Language Conforme che è capace di accettare un documento SSML in input e produrre un output vocale usando le informazioni contenute nel testo marcato per renderizzare il documento come voleva l'autore. Uno User Agent Conforme deve supportare almeno un linguaggio naturale.
Dal momento che non è garantito che l'output sia una corretta rappresentazione del contenuto del testo marcato in input, non ci sono requisiti di conformità riguardo l'accuratezza. Un test di conformità può, comunque, prevedere alcuni esempi di corretta sintesi di documenti di riferimento per determinarne la conformità.
2.3 Integrazione con altri Linguaggi di Marcatura
Il Synchronized Multimedia Integration Language (SMIL, si legge "smile") [SMIL] permette di realizzare semplici presentazioni audiovisive interattive. Lo SMIL viene di solito usato per presentazioni "rich media"/multimediali che uniscono audio in streaming con video, immagini, testo ed altri media. Lo SMIL è un linguaggio simile all'HTML semplice da imparare, e molte presentazioni SMIL vengono scritte usando un semplice editor di testo. Per vedere degli esempi di integrazione SMIL/SSML si veda l'Appendice F.
Gli Aural Cascading Style Sheet [CSS2 §19] vengono impiegati per espandere il formato standard dei documenti (come l'HTML) con elementi addizionali che aiutano nella sintesi del testo in suono.
Confrontati con l'SSML, i documenti generati con ACSS sono capaci di fornire informazioni più precise sulla sequenza audio, inclusa la definizione dello spazio 3-dimensionale della sorgente del suono. Molti degli altri elementi dell'ACSS sovrastano le funzionalità dell'SSML, specialmente nelle specifiche riguardo il tipo e la qualità della voce. L'SSML può essere visto come un insieme che contiene le capacità dell'ACSS, eccetto per l'audio spaziale.
Il Voice Extensible Markup Language [VXML] permette lo sviluppo sul Web e la distrubuzione di applicazioni interattive a risposta vocale (si veda browser vocale ). Il VoiceXML supporta la sintesi vocale, la registrazione e la riproduzione di audio digitale, il riconoscimento vocale, l'input DTMF, il controllo delle chiamate telefoniche e i dialoghi basati su form.
Il VoiceXML 2.0 estende l'SSML per la marcatura del testo da sintetizzare. Per un'esempio di integrazione tra il VoiceXML e l'SSML si veda l'Appendice F.
Il recupero e le politiche di caching dei documenti SSML sono definite dall'ambiente in cui il sintetizzatore vocale opera. Nel contesto dell'interprete VoiceXML, per esempio, le politiche di caching sono definite dall'interprete VoiceXML.
3. Elementi ed Attributi
In questa specifica vengono definiti i seguenti elementi ed attributi.
3.1 Struttura del Documento, Elaborazione del Testo e Pronuncia 3.1.1 Elemento radice "speak"
3.1.5 Elemento "meta"
3.1.6 Elemento "metadata"
3.1.8 Elemento"say-as"
3.1.10 Elemento "sub"
3.1 Struttura del Documento, Elaborazione del Testo e Pronuncia
3.1.1 Elemento Radice speak
Lo Speech Synthesis Markup Language è un'applicazione dell'XML. L'elemento radice è speak. xml:lang è un'attributo necessario che specifica la lingua del documento radice. xml:base è un'attributo opzionale che specifica l'URI di base del documento radice. L'attributo version è un'attributo necessario che indica la versione della specifica da usare per il documento e deve avere il valore "1.0".
... corpo del documento ...
L'elemento speak può contenere solo testo da renderizzare e i seguenti elementi: audio, break, emphasis, lexicon, mark, meta, metadata, p, phoneme, prosody, say-as, sub, s, voice.
3.1.2 Lingua: Attributo xml:lang
L'attributo xml:lang, come definito dall'XML 1.0 [XML §2.12], può essere usato nell'SSML per indicare il linguaggio naturale degli elementi contenuti e i suoi attributi e sottoelementi. L'RFC 3066 [RFC3066] può essere utile per capire come usare questo attributo.
Le informazioni sulle lingua vengono ereditate nella grarchia del documento, per esempio possono essere date solo una volta se l'intero documento è in una lingua, e possono essere annidate, perciò gli attributi più interni sovrascrivono quelli più esterni.
xml:lang è un attributo definito per gli elementi voice, speak, p, e s. Per il rendering vocale, un cambio di lingua può avere effetti su vari parametri (compresi genere, velocità, età, tono, ecc.) che possono disturbare l'ascolto. Potrebbero esserci anche delle pause non naturali tra i cambi di lingua.
Per questa ragione, gli autori vengono incoraggiati ad usare l'elemento voice per cambiare la lingua. xml:lang è consentito su p e s solo perché è comune cambiare lingua a questi livelli.
Sebbene questo attributo sia consentito per l'elemento desc, nessun cambio di voce descritto in questo sezione viene applicato se usato con questo elemento.
&lt;p&gt;I don't speak Japanese.&lt;/p&gt;
&lt;p xml:lang="ja"&gt;日本語が分かりません。&lt;/p&gt;
Nel caso in cui un documento richieda un output vocale in una lingua non supportata dal sintetizzatore, il sintetizzatore vocale determina un certo comportamento. Specificando xml:lang non siamo certi che ci sia un cambio della voce, anche se questo può capitare. Quando una certa voce non riesce a leggere il contenuto nella lingua indicata, il sintetizzatore può scegliere un'altra voce. Non ci sono cambi di voce o di prosodia se il valore di xml:lang è uguale al valore ereditato. Maggiori informazioni sulla selezione della voce si trovano nella Sezione 3.2.1.
Possono esistere delle variazioni tra sintetizzatori conformi nell'implementazione delle modifiche della lingua con xml:lang tra diversi elementi di marcatura (per esempio gli elementi p e s).
Ogni elemento dovrebbe elaborare il suo contenuto in relazione alla lingua in cui è inserito. Per esempio, gli elementi phoneme, emphasis, break, p e s dovrebbero essere renderizzati in modo appropriato alla lingua corrente.
I passaggi della normalizzazione del testo possono essere influenzati dalla lingua. Questo è vero sia per il supporto di marcatura per l'elemento say-as che senza marcatura. Nel seguente esempio il testo "2/1/2000" può essere letto come "February first two thousand" nella prima frase, seguendo le regole dell'Inglese Americano, o come "the second of January two thousand" nella seconda, seguendo le regole del preprocessore Italiano.
3.1.3 URI di base: Attributo xml:base
Gli URI relativi vengono risolti secondo un URI di base, che può venire da diverse fonti. La dichiarazione dell'URI di base permette agli autori di specificare esplicitamente un URI di base per il documento. Si veda la Sezione 3.1.3.1 per dettagli sulla risoluzione degli URI relativi.
La dichiarazione dell'URI di base è permessa ma opzionale. I due elementi influenzati da questa sono
L'attributo opzionale src può specificare un URI relativo.
L'attributo uri può specificare un URI relativo.
L'attributo xml:base
La dichiarazione dell'URI di base segue [XML-BASE] ed è indicata da un attributo xml:base sull'elemento radice speak.
3.1.3.1 Risolvere URI relativi
Gli User agent devono calcolare l'URI di base per la risoluzione degli URI relativi in base all'[RFC2396]. Segue la descrizione di come l'RFC2396 si applica ai documenti di sintesi.
Gli User agent devono calcolare l'URI di base in base alle seguenti precedenze (dalla più alta alla più bassa):
L'URI di base viene impostato dall'attributo xml:base sull'elemento speak (si veda la Sezione 3.1.3).
L'URI di base viene fornito attraverso metadata trasmessi durante un'interazione di protocollo, come per gli header HTTP (si veda l'[RFC2616]).
Se non viene specificato altrimenti, l'URI di base è quello del documento corrente. Non tutti i documenti di sintesi hanno un URI di base (per esempio, un documento di sintesi valido può comparire in un'email e quindi non avere un URI). È un errore se documenti del genere contengono URI relativi.
3.1.4 Lessico di Pronuncia: Elemento lexicon
Un documento SSML può fare riferimento ad uno o più documenti di lessico di pronuncia esterni. Un documento di lessico è identificato da un URI con un tipo di media opzionale. Non sono stati ancora definiti tipi di media standard per il lessico come predefiniti per questa specifica.
Il Voice Browser Working Group del W3C sta sviluppando il Linguaggio di Marcatura per il Lessico di Pronuncia [LEX]. La specifica darà indicazioni sul processo di corrispondenza tra i token, il lessico e il modo in cui un sintetizzatore vocale gestisce le pronunce tra lessici interni e specifici della sintesi. La gestione della pronuncia con formati di lessico proprietari deve essere necessariamente specificata al sintetizzatore vocale.
Un documento di lessico contiene le informazioni di pronuncia per i token che possono apparire nel testo da leggere. Le informazioni di pronuncia contenute in un lessico vengono udate per i token che compaiono nel documento di riferimento.
I lessici di pronuncia sono necessariamente specifici di ogni certa lingua. La ricerca della pronuncia nel lessico e la deduzione della pronuncia per ogni token (o unità di testo) può usare un algoritmo che è specifico della lingua. Come riportato nella Sezione 1.2, la definizione di cosa costituisce un "token" può essere anch'essa specifica della lingua.
Quando si fa riferimento a lessici multipli, la loro precedenza va dal più basso al più alto con l'ordine del documento. Precedenza significa che un token viene prima cercato nel lessico con la precedenza maggiore. Solo se non viene trovato in quel lessico, viene analizzato il prossimo lessico e così via fino alla prima occorrenza o fino a che tutti i lessici non sono stati usati per la ricerca.
L'elemento lexicon
Può apparire un numero arbitrario di elementi lexicon come figli immediati dell'elemento speak.
L'elemento lexicon deve avere un attributo uri specificando un URI che identifica la locazione del documento di lessico di pronuncia.
L'elemento lexicon può avere un attributo type che specifica un tipo di media per il documento di lessico di pronuncia.
&lt;lexicon uri="http://www.example.com/lexicon.file"/&gt;
Dettagli sull'attributo type
Nota: la descrizione e la tabella che seguono, usano il tipo di lessico (immmaginario) di un'ipotetica azienda x-vnd.example.lexicon. Questo intende rappresentare un qualunque formato disponibile.
Un risorsa di lessico indicata da un riferimento URI può essere disponibile in uno o più tipi di media. L'autore di SSML può specificare il tipo di media preferito attraverso l'attributo type. Quando i contenuti rappresentati da un URI sono disponibili in diversi formati, un sintetizzatore vocale può usare il tipo preferito per influenzare la scelta del formato da usare. Per esempio, su un server che implementa la negoziazione dei contenuti via HTTP, il sintetizzatore può usare il tipo per ordinare le preferenze nella negoziazione.
Per quanto concerne la consegna, la risorsa indicata da un riferimento URI può essere consideta in due modi. Il tipo di media dichiarato è il valore allegato alla risorsa e il tipo di media reale è il vero formato del contenuto. Il tipo effettivo dovrebbe essere uguale al tipo dichiarato, ma non succede sempre (ad esempio, un server HTTP malconfigurato potrebbe restituire text/plain per un documento che appartiene al formato x-vnd.example.lexicon). Uno specifico schema URI potrebbe richiedere che il proprietario della risorsa restituisca sempre, a volte o mai, un tipo di media. Se viene fornito un tipo, questo viene trattato come autoritativo. Il tipo di media dichiarato viene determinato tramite il valore restituito dal proprietario della risorsa o, se non viene restituito alcun vvalore, dal tipo di media preferito scritto nel documento SSML Sono previsti tre casi speciali. Il tipo di media dichiarato potrebbe non essere supportato dal sintetizzatore; questo è un errore. Il tipo dichiarato potrebbe essere supportato ma non corrisponde al tipo effettivo; anche questo è un errore. Infine, potrebbe non essere dichiarato alcun tipo di media; il comportamento dipende dallo specifico schema URI e dalle capacità del sintetizzatore vocale. Per esempio, l'HTTP 1.1 prevede l'introspezione nei documenti (si legga [RFC2616 §7.2.1]), lo schema dei dati ricade in un tipo di media predefinito, e l'accesso a file locali non definisce politiche di alcun tipo. La seguente tabella fornisce alcuni esempi esplicativi: Esempi di tipi di media
richiesta HTTP 1.1
Accesso al file locale
Tipo di media restituito dal proprietario della risorsa
Tipo di media preferito per il documento SSML
Non applicabile; il tipo di media restutuito è autoritativo.
Tipo di media dichiarato
Comportamento per il tipo di media vero x-vnd.example.lexicon
Deve essere elaborato come text/plain. Questo genera un errore se text/plain non è supportato o se il documento non segue il formato atteso.
Il tipo dichiarato e quello reale coincidono; viene elaborato con successo se x-vnd.example.lexicon è supportato dal sintetizzatore vocale; altrimenti c'è un error.
Specifico dello schema; il sintetizzatore deve introspezionare il documento per identificare il tipo.
L'elemento lexicon è un elemento vuoto.
3.1.5 Elemento meta
Gli elementi metadata e meta sono contenitori dove si possono scrivere informazioni sul documento. L'elemento metadata prevede un trattamento più generale e potente delle informazioni metadata contrapposto all'uso di meta con uno schema metadata.
Un dichiarazione meta associa una stringa ad un una proprietà meta dichiarata o dichiara un contenuto "http-equiv". Uno degli attributi name o http-equiv è richiesto. È un errore fornire entrambi gli attributi name e http-equiv. È richiesto anche l'attributo content. La proprietà seeAlso è l'unico nome di proprietà meta definito. Viene usato per specificare una risorsa che fornisce informazioni aggiuntive sul contenuto. Questa proprietà è modellata sulla proprietà seeAlso della Resource Description Framework (RDF) Schema Specification 1.0 [RDF-SCHEMA §5.4.1]. L'attributo http-equiv ha un significato speciale quando i documenti vengono scaricati via HTTP. Sebbene la via preferenziale per fornire informazioni di intestazione HTTP sia quella di usare campi HTTP header, il contenuto di "http-equiv" può essere usato quando l'autore di documenti SSML non può configurare i ccampi di intestazione HTTP associati al suo documento sul server di origine, per esempio, informazioni di controllo sulla cache. Si noti che i server HTTP e le cache non hanno bisogno di introspezionare il contenuto di meta nei documenti SSML e per questo sovrascrive i valori di intestazione che avrebbero spedito altrimenti.
Informazione: Questo è un esempio di come elementi meta possano essere inclusi in un doccumento SSML per specificare una risorsa che fornisce informazioni metadata aggiuntive e che in più indica che il documento non deve essere mantenuto in cache.
L'elemento meta è un elemento vuoto..
3.1.6 Elemento metadata
L'elemento metadata è un contenitore dove possono essere scritte informazioni sul documento usando uno schema metadata. Sebbene ogni schema metadata possa essere usato con metadata, si raccomanda che la sintassi XML del Resource Description Framework (RDF) [RDF-XMLSYNTAX] venga usata insieme alle proprietà metadata generali definite nella Dublin Core Metadata Initiative [DC].
Il Resource Description Format [RDF] è un linguaggio dichiarativo che fornisce un metodo standard per usare l'XML per rappresentare metadata in forma di istruzioni sulle proprietà e relazioni di oggetti sul Web. I creatori di contenuti dovrebbero far riferimento alla W3C metadata Recommendations [RDF-XMLSYNTAX] e [RDF-SCHEMA] nel decidere quale schema RDF metadata usare nei propri documenti. I creatori di contenuti dovrebbe leggere anche la Dublin Core Metadata Initiative [DC], che è un insieme di proprietà metadata applicabili genericamente (per esempio, Title, Creator, Subject, Description, Rights, ecc.).
Le proprietà del documento dichiarate con un elemento metadata possono usare qualunque schema metadata.
Informazione: Questo è un esempio di come i metadata possono essere inclusi in un documento SSML usando lo schema RDF del Dublin Core versione 1.0 [DC] che descrive informazioni generali sul documento, quali titolo, descrizione, data e così via:
&lt;!-- Metadata sul documento di sintesi --&gt;
L'elemento metadata può avere contenuto arbitrario, visto che il suo contenuto non sarà analizzato dal sintetizzatore vocale.
3.1.7 Struttura del Testo: Elementi p e s
L'elemento p rappresenta un paragrafo. L'elemento s rappresenta una frase.
xml:lang è un attributo definito sugli elementi p e s.
&lt;s&gt;Questa &egrave; la prima frase del paragrafo.&lt;/s&gt;
&lt;s&gt;Ecco un'altra frase.&lt;/s&gt;
L'uso degli elementi p e s è opzionale. Quando il testo non compare racchiuso tra elementi p o s, il sintetizzatore vocale tenterà di determinare la struttura usando conoscenze specifiche della lingua sul formato del testo semplice.
L'elemento p può contenere solo testo che deve essere sintetizzato e i seguenti elementi: audio, break, emphasis, mark, phoneme, prosody, say-as, sub, s, voice.
L'elemento s può contenere solo testo che deve essere sintetizzato e i seguenti elementi: audio, break, emphasis, mark, phoneme, prosody, say-as, sub, voice.
3.1.8 Elemento say-as
L'elemento say-as permette all'autore di indicare informazioni sul tipo di costrutto linguistico contenuto nell'elemento e di specificare il livello di dettaglio per la sintesi del testo contenuto.
Definire un insieme esaustivo di tipi di formato di testo è difficile a causa della varietà di lingue che devono essere considerate e dell'innata flessibilità della lingua scritta. L'SSML specifica solo l'elemento say-as, i suoi attributi e il loro scopo. Non enumera tutti i possbili valori degli attributi. Il Gruppo di Lavoro spera di produrre un documento separato che definisca valori standard e i comportamenti associati a questi valori. Gli esempi ivi forniti servono soltanto ad illustrare gli obiettivi dell'elemento e i suoi attributi.
L'elemento say-as ha tre attributi: interpret-as, format e detail. L'attributo interpret-as è sempre necessario; gli altri due sono opzionali. I volori ammessi per l'attributo format dipendono dal valore dell'attributo interpret-as.
L'elemento say-as può contenere esclusivamente testo da sintetizzare.
Attributi interpret-as e format
L'attributo interpret-as indica il tipo di contenuto del costrutto di testo. Specificare il tipo di contenuto assiste il sintetizzatore vocale a distinguere e interpretare i costrutti di testo che possono essere sintetizzati in modi diversi a seconda del tipo di informazioni che vogliono fornire. Inoltre, l'attributo opzionale format può dare ulteriori consigli sulla precisa formattazione del testo contenuto per i tipi che potrebbero avere formati ambigui.
Se specificati, i valori di interpret-as e format saranno interpretati dal sintetizzatore vocale come consigli forniti dall'autore di documenti di markup per assistere la normalizzazione del testo e la pronuncia.
In ogni caso, il testo racchiuso tra elementi say-as deve essere inteso come una forma ortografica standard della lingua correntemente in uso nel contesto. Il sintetizzatore vocale dovrebbe essere capace di supportare la forma ortografica comune della lingua specificata per ogni contenuto del tipo che supporta.
Quando il valore dell'attributo interpret-as è sconosciuto o non supportato dal sintetizzatore, il testo contenuto deve essere sintetizzato come se non fosse stato specificato alcun valore interpret-as.
Quando il valore dell'attributo format è sconosciuto o non supportato dal sintetizzatore, il testo contenuto deve essere sintetizzato come se non fosse stato specificato alcun valore format e dovrebbe riprodurlo usando il valore di interpret-as che è specificato.
Quando l'elemento say-as contiene testo aggiuntivo insieme al contenuto che è indicato nei tipi format e interpret-as, questo testo aggiuntivo deve essere renderizzato. Il sintetizzatore dovrebbe procedere alla renderizzazione del testo aggiuntivo in base al tipo interpret-as dell'elemento nel quale appare.
Quando il contenuto di say-as non ha niente all'interno del tipo interpret-as o di format, il sintetizzatore deve renderizzare il contenuto come se l'attributo format non fosse presente, o come se l'attributo interpret-as non fosse presente, o come se nessuno degli attributi format e interpret-as fossero presenti. Il sintetizzatore deve altresì notificare l'ambiente di esecuzione del fatto.
Indicare il tipo di contenuto o il suo formato non influenza necessariamente il modo in cui le informazionii vengono riprodotte. Il sintetizzatore vocale dovrebbe pronunciare il testo come viene normalmente letto in quella lingua.
Attributo detail
L'attributo detail è un attributo opzionale che indica il livello di dettaglio per la renderizzazione. Ogni valore dell'attributo detail deve sintetizzare tutto il contenuto informativo del testo; comunque, valori specifici di detail possono essere usati per sintetizzare il contenuto che rimane informativo nel testo corrente ma che può essere importante per la lettura. Per esempio, un sintetizzatore vocale di solito sintetizza la punteggiatura attraverso cambiamenti nel ritmo di lettura. Impostare un alto livello di dettaglio permette di pronunciare esplicitamente la punteggiatura, per esempio per leggere numeri di pezzi di codice o parti di listati in modo corretto.
L'attributo detail può essere usato per tutti i tipi interpret-as.
Se l'attributo detail non è specificato, il livello di dettaglio della riproduzione del sintetizzatore vocale dipende dal testo e dalla lingua.
Se il valore dell'attributo detail è sconosciuto o non supportato dal sintetizzatore, deve sintetizzare il testo contenuto come se non fosse stato specificato alcun valore per l'attributo detail.
3.1.9 Elemento phoneme
L'elemento phoneme fornisce la fonetica per il testo contenuto. L'elemento phoneme deve essere vuoto. Comunque, si raccomanda che l'elemento contenga testo leggibile da persone, che possa essere usato anche per produzioni non vocali del documento. Per esempio, il contenuto potrebbe essere visualizzato per utenti con problemi uditivi..
L'attributo ph è un attributo necessario che specifica la stringa fonetica.
Questo elemento è progettato specificamente per la notazione fonemica e fonetica e viene usato per descrivere la pronuncia di parole e frasi corte. La stringa fonemica/fonetica non sostituisce la normalizzazione del testo ed non viene trattata come un token nella ricerca nel lessico (si veda la Sezione 3.1.4), anche se entrambi i valori di say-as e sub possono sostituirsi a questa.
In breve, le stringhe fonemiche sono formate da fonemi, unità vocali dipendenti dalla lingua che caratterizzano le differenze più significative tra le lingue; a grandi linee, i fonemi rappresentano tutti i suoni necessari per distinguere una parola da un'altra. Dall'altra parte, le stringhe fonetiche sono fatte da suoni, unià vocali che caratterizzano il modo (sussurrato, squillante, cantato, ecc.) e il luogo (davanti, in mezzo, dietro, ecc.) della pronuncia nei tratti vocali umani e sono quindi indipendenti dalla lingua; i suoni rappresentano le varietà della dialogica umana.
L'attributo alphabet è un attributo opzionale che specifica l'alfabeto fonetico. L'alfabeto, in questo contesto, è una collezione di simboli che rappresentano i suoni di una o più lingue.
Gli unici valori validi per questo attributo sono "ipa" (si veda il prossimo paragrafo) e stringhe specifiche dei produttori nella forma "x-organization" o "x-organization-alphabet". Per esempio, la Japan Electronics and Information Technology Industries Association [JEITA] potrebbe incoraggiare l'uso di un alfabeto del tipo "x-JEITA" o "x-JEITA-2000" per i loro alfabeti fonetici [JEIDAALPHABET].
I sintetizzatori vocali dovrebbero supportare il valore "ipa" dell'attributo alphabet, che corrisponde alla rappresentazione Unicode dei caratteri fonetici sviluppata dalla International Phonetic Association [IPA]. In aggiunta al completo insieme di vocali e consonanti, questo insieme di caratteri supporta un delimitatore di sillabe, numerosi segni diacritici, simboli di accento, simboli di tono lessicale, marcatori di intonazione ed altro ancora. Per questo alfabeto, o valori ammessi per ph sono stringhe dei valori specificati nell'Appendice 2 di [IPAHNDBK].
Tabelle informative sulla mappatura IPA-to-Unicode si trovano su [IPAUNICODE1] e [IPAUNICODE2]. Si noti che non tutti i caratteri IPA sono disponibili in Unicode. Per i sintetizzatori che supportano questo alfabeto vale che,
Il sintetizzatore deve accettare sintatticamente tutti i valori legittimi di ph.
Il sintetizzatore deve produrre un risultato quando vengono specificati codici Unicode IPA che ragionevolmente appartengono alla lingua corrente.
La produzione del risultato, quando vengono forniti altri codici, è completamente a discrezione del sintetizzatore.
&lt;!-- Questo &egrave; un esempio di IPA che usa entit&agrave; carattere --&gt;
&lt;!-- Visto che molte combinazioni di piattaforme/browser/editor di testo non copiano e
incollano correttamente testo Unicode, questo esempio usa la versione con escape
dell'entit&agrave; del carattere IPA. Di solito si usa direttamente la rappresentazione
UTF-8 di questi simboli: "təmei̥ɾou̥". --&gt;
È un errore se un valore di alphabet è specificato che non è conosciuto o non può essere applicato dal sintetizzatore vocale.
La scelta del comportamento da tenere quando l'attributo alphabet non è specificato è lasciata al sintetizzatore.
L'elemento phoneme può contenere solo testo (senza elementi).
3.1.10 Elemento sub
L'elemento sub viene impiegato per indicare che il testo nel valore dell'attributo alias rimpiazza il testo per la pronuncia. Questo permette al documento di avere sia un contenuto per la forma scritta, che uno per la forma orale. L'attributo necessario alias specifica la stringa che dovrà essere letta al posto del testo racchiuso. Il sintetizzatore dovrebbe applicare una normalizzazione del testo al valore di alias.
L'elemento sub può contenere solo testo (senza elementi).
3.2 Prosodia (o metrica) e Stile
3.2.1 Elemento voice
L'elemento voice è un elemento di produzione che richiede un cambio nella voce parlante. Gli attributi sono:
xml:lang : attributo opzionale che specifica la lingua.
gender: attributo opzionale che indica il genere preferito della voce che legge il testo contenuto. I valori possibili sono: "male" (maschio), "female" (femmina), "neutral" (neutro).
age: attributo opzionale che indica l'età preferita in anni (dalla nascita) della voce che legge il testo contenuto. Valori accettabili sono quelli di tipo xsd:nonNegativeInteger [SCHEMA2 §3.3.20].
variant: attributo opzionale che indica la variante preferita delle altre caratteristiche della voce che legge il testo contenuto. (per esempio, la seconda voce di bambino). Valori validi per variant sono quelli di tipo xsd:positiveInteger [SCHEMA2 §3.3.25].
name: attributo opzionale che indica il nome di una voce dello specifico sintetizzatore per la lettura del testo contenuto. Il valore può essere una lista separata da spazi di nomi ordinati per preferenza, dal più preferito al meno preferito. Da ciò segue che un nome non può contenere spazi bianchi.
Sebbene ciascun attributo sia individualmente opzionale, è un errore non specificare alcun attributo quando si usa l'elemento voice.
&lt;voice gender="female"&gt;Mary has a little sheep,&lt;/voice&gt;
&lt;!-- adesso richiedo una vode diversa di bambina --&gt;
&lt;!-- selezione di una voce specifica del sintetizzatore --&gt;
&lt;voice name="Mike"&gt;I want to be like Mike.&lt;/voice&gt;
L'elemento voice viene comunemente usato per cambiare lingua. Quando non è disponibile una voce che corrisponda esattamente agli attributi specificati nel documento, e ci sono più voci che corrispondono a quei criteri, viene usato il seguente algoritmo di selezione. Ci sono casi ambigui nell'algoritmo; in questi casi la selezione della voce viene lasciata al sintetizzatore. In modo approssimativo, l'attributo xml:lang ha la più alta priorità e tutti gli altri attributo sono identici come priorità ma stanno dopo xml:lang . L'algoritmo completo è:
Se una voce è disponibile per lo xml:lang richiesto, il sintetizzatore vocale la deve usare. Se sono disponibili più voci di questo tipo, il sintetizzatore dovrebbe usare la voce che più soddisfa i valori specificati di name, variant, gender ed age.
Se non ci sono voci disponibili per lo xml:lang richiesto, il sintetizzatore dovrebbe selezionare la voce che risulta più somigliante alla lingua richiesta (per esempio, una variante o un dialetto della stessa lingua). Se sono disponibili più voci di questo tipo, il sintetizzatore dovrebbe usare la voce che più soddisfa i valori specificati di name, variant, gender ed age.
È un errore se il sintetizzatore decide che non esiste una voce che corrisponde sufficientemente ai criteri richiesti.
Si noti che possono essere fatti semplici inserimenti di testo in lingua straniera (dove un cambio di voce non è necessario o non desiderato). Si veda l'Appendice F per alcuni esempi.
Gli attributi di voice vengono ereditati nell'albero degli elementi, inclusi all'interno degli elementi che cambiano la lingua.
Here a female voice.
Here a female child voice.
&lt;p xml:lang="ja"&gt;
&lt;!-- Una voce di bambina in giapponese. --&gt;
Cambiamenti sui parametri di metrica possono essere mantenuti tra cambi di voce. Comunque, bisogna notare che voci diverse hanno naturalmente parametri diversi per quanto riguarda tono, velocità di lettura ecc. a causa delle diverse
personalità che rappresentano, quindi i valori assoluti dei parametri di metrica possono variare tra cambi di voce.
La qualità del suono risultante e della voce può peggiorare se viene richiesto un cambio di voce all'interno di una frase.
L'elemento voice può contenere solo testo da sintetizzare e i seguenti elementi: audio, break, emphasis, mark, p, phoneme, prosody, say-as, sub, s, voice.
3.2.2 Elemento emphasis
L'elemento emphasis richiede che il testo contenuto al suo interno sia letto con enfasi (con risalto, con forza). Il sintetizzatore vocale definisce come sintetizzare l'enfasi, tenendo conto del fatto che ogni lingua, dialetto e perfino ogni voce enfatizza in modo diverso. Gli attributi sono:
level: l'attributo opzionale level indica la forza dell'enfasi che dovrà essere applicata. Valori predefiniti sono "strong" (forte), "moderate" (moderato), "none" (nessuno) and "reduced" (ridotto).
Il valore predefinito di level è "moderate". Il significato di enfasi "strong" e "moderate" è da interpretare in relazione alla lingua usata per parlare (la lingua definisce l'enfasi usando una combinazione di modifica del tono, della tempistica, del volume e di altri parametri acustici). Il valore "reduced" di level costituisce l'opposto dell'enfasi. Per esempio (n.d.t. solo per chi conosce l'inglese), quando la frase "going to" viene specificata con "reduced", potrebbe essere letta come "gonna". Il valore "none" di level viene usato per impedire al sintetizzatore vocale di enfatizzare le parole che di solito verrebbero enfatizzate. I valori "none", "moderate" e "strong" sono monotonicamente non-decrescenti come forza.
This is a &lt;emphasis&gt; great &lt;/emphasis&gt; car!
You have a &lt;emphasis level="strong"&gt; huge &lt;/emphasis&gt;
L'elemento emphasis può contenere solo testo da sintetizzare e i seguenti elementi: audio, break, emphasis, mark, phoneme, prosody, say-as, sub, voice.
3.2.3 Elemento break
L'elemento break è un elemento vuoto che controlla le pause e altri limiti di metrica tra parole. L'uso di break tra ogni coppia di parole è opzionale.
Se l'elemento non è presente tra le parole, il sintetizzatore vocale dovrebbe automaticamente determinare una pausa basandosi sul contesto linguistico. Nella pratica, l'elemento break viene spesso usato per superare il comportamento automatico del sintetizzatore. Gli attributi di questi elemento sono:
strength: l'attributo strength è un attributo opzionale che prende uno dei seguenti valori: "none", "x-weak", "weak", "medium" (valore di default), "strong" o "x-strong". Questo attributo serve per indicare la forza dell'intervallo metrico nella lettura. Il valore "none" indica che non deve essere prodotto alcun intervallo, e può essere usato per evitare l'eventuale pausa che sarebbe stata inserita in automatico dal sintetizzatore. Gli altri valori indicano la forza dell'interruzione tra le parole e sono elencati in modo monotonicamente non-decrescente (concettualmente crescente). Le interruzioni più forti sono tipicamente accompagnate da pause. I valori "x-weak" e "x-strong" sono abbreviazioni di "extra weak" e "extra strong", rispettivamente.
time: l'attributo time è un attributo opzionale che indica la durata della pausa che dovrà essere inserita nell'output vocale in secondi o millisecondi. Segue il formato del tempo della Cascading Style Sheets Level 2 Recommendation [CSS2], ad esempio, "250ms", "3s".
L'attributo strength viene usato per indicare la forza metrica dell'interruzione. Per esempio, le pause tra paragrafi sono di solito più forti di quelle tra parole all'interno di una frase. Il sintetizzatore vocale può inserire una pausa come parte della sua implementazione delle interruzioni metriche. Una pausa di una certa lunghezza può essere anche inserita usando l'attributo time.
Se l'elemento break viene usato senza gli attributi strength e time, verrà prodotta dal sintetizzatore una pausa con una forza metrica maggiore di quanto sarebbe stato se l'elemento break non fosse stato specificato.
Se vengono specificati entrambi gli attributi strength e time, il sintetizzatore inserirà una pausa con la durata specificata dall'attributo time, insieme ad altre modifiche di metrica in base al valore dell'attributo strength.
Press 1 or wait for the bell. &lt;break time="3s"/&gt;
I cannot understand! &lt;break strength="weak"/&gt; Repeat please.
3.2.4 Elemento prosody
L'elemento prosody permette il controllo di tono, velocità di lettura e volume dell'output vocale. Gli attributi, tutti opzionali, sono:
pitch: il tono fondamentale per il testo contenuto. Sebbenne l'esatto significato di "tono fondamentale" varia molto tra sintetizzatori vocali, l'aumento/diminuzione di questo valore di solito provoca l'aumento/diminuzione del tono approssimativo del risultato. Valori ammessi sono: un numero seguito da "Hz", una correzione relativa o "x-low", "low", "medium", "high", "x-high", o "default". I valori da "x-low" a "x-high" rappresentano una sequenza di livelli di tono monotonicamente non-decrescente.
contour: imposta il profilo effettivo del tono per il testo contenuto. Il formato è specificato in Profilo tonico qui sotto.
range: l'intervallo di altezza (variabilità) per il testo contenuto. Sebbene l'esatto significato di "intervallo di altezza" possa variare tra diversi sintetizzatori, l'aumento/diminuzione di questo valore di solito provoca l'aumento/diminuzione dell'intervallo dinamico dell'altezza dell'output. Valori ammessi sono: un numero seguito da "Hz", una correzione relativa o "x-low", "low", "medium", "high", "x-high" o "default". I valori da "x-low" a "x-high" rappresentano una sequenza di intervalli di altezza monotonicamente non-descrescente.
rate: una modifica della frequenza nella lettura per il testo contenuto. Valori ammessi sono: una correzione relativa o "x-slow", "slow", "medium", "fast", "x-fast" o "default". I valori tra "x-slow" e "x-fast" rappresentano una sequenza di frequenze di lettura monotonicamente non-decrescenti. Quando viene usato un numero per specificare una correzione relativa, questo agisce come un moltiplicatore per la frequenza predefinita. Per esempio, un valore di 1 significa mantieni la frequenza, 2 significa una frequenza doppia di quella predefinita e un valore di 0.5 significa metà della frequenza prefedinita. La frequenza predefinita di una voce dipende dalla lingua, dal dialetto e dalla personalità della voce. La frequenza predefinita di una voce deve uguagliare la frequenza normale della voce reale. Visto che le voci sono specifiche del sintetizzatore, anche le frequenze predefinite lo sono.
duration: un valore, in secondi o millisecondi, che indica il tempo che deve impiegare il sintetizzatore a leggere il contenuto dell'elemento. Segue il formato di tempo della Cascading Style Sheet Level 2 Recommendation [CSS2], per esempio, "250ms", "3s".
volume: il volume del testo contenuto, compreso tra 0.0 e 100.0 (valori più alti indicano volume più alto, specificando zero, indichiamo "silent", in silenzio).
Valori ammessi sono: un numero, una correzione relativa o "silent", "x-soft", "soft", "medium", "loud", "x-loud" o "default". La scala del volume è un'ampiezza lineare. Il valore predefinito è 100.0. I valori da "silent" a "x-loud" rappresentano una sequenza di livelli di volume monotonicamente non-decrescente.
Sebbene ogni attributo sia individualmente opzionale, è un errore non specificare alcun attributo quando si usa l'elemento prosody. I valori del tipo "x-qualcosa " sono contrazioni di "extra qualcosa". Tutte le unità ("Hz", "st") devono essere specificate con il caso giusto (maiuscolo o minuscolo).
Si noti inoltre che le altezze personalizzate e gli intervalli standard di altezza possono variare significativamente tra lingue diverse, come possono variare i significati dei valori ammessi per le altezze e gli intervalli.
Un numero è un semplice valore in virgola mobile positivo senza parte esponenziale. Formati ammessi sono "n", "n.", ".n" e "n.n", ove "n" è una sequenza di una o più cifre.
Correzioni relative
Correzioni relative per gli attributi possono essere specificati
come percentuale (un numero opzionalmente preceduto da "+" o "-" e seguito da "%"), per esempio "3%", "+15.2%", "-8.0%", o
come un numero relativo: Per l'attributo rate, le correzioni relative sono un numero.
Per l'attributo volume, le correzioni relative sono un numero preceduto da "+" o "-", per esempio, "+10", "-5.5".
Per gli attributi pitch e range, le correzioni relative possono essere specificate come semitoni (un numero preceduto da "+" o "-" e seguito da "st") o in Hertz (un numero perceduto da "+" o "-" e seguito da "Hz"): "+0.5st", "+5st", "-2st", "+10Hz", "-5.5Hz". Un semitono è metà di un tono sulla scala diatonica standard.
The price of XYZ is &lt;prosody rate="-10%"&gt; $45 &lt;/prosody&gt;
Profilo tonico
Il profilo tonico è definito come un insieme di target separati da spazi bianchi in posizioni di tempo specifiche nell'output vocale. L'algoritmo per l'interpolazione tra le definizioni è specifico per ciascun sintetizzatore. In ogni coppia della forma (posizione temporale, target), il primo valore è una percentuale del tempo di lettura del testo contenuto (un numero seguito da "%") e il secondo valore è il valore dell'attributo pitch (un numero seguito da "Hz", una correzione relativa o una etichetta). Le posizioni temporali esterne all'intervallo tra 0% e 100% vengono ignorate. Se non è definito alcun valore di altezza per 0% o per 100%, viene scelto il target più vicino. Tutte le correzioni relative per l'altezza sono relative all'altezza che precedeva l'elemento.
L'attributo duration ha precedenza sull'attributo rate.
L'attributo contour ha precedenza sugli attributi pitch e range.
Il valore di default di tutti gli attributi di metrica è nessuna modifica. Per esempio, se non si specifica l'attributo rate significa che vogliamo che la frequenza rimanga invariata rispetto il testo precedente.
L'elemento prosody può contenere solo testo da sintetizzare e i seguenti elementi: audio, break, emphasis, mark, p, phoneme, prosody, say-as, sub, s e voice.
Tutti gli attributi di metrica sono indicativi. Se il sintetizatore vocale non riesce a sintetizzare in modo accurato il documento come specificato (per esempio, provando ad impostare il tono a 1Mhz o la frequenza di lettura a 1.000.000 di parole per minuto), deve compiere uno sforzo per continuare ad elaborare il documento imponendo un limite o sostituendo i valori specificati e non supportati, e deve informare l'ambiente di esecuzione del superamento di tali limiti.
In alcuni casi, il sintetizzatore vocale può scegliere di ignorare un certo elemento di metrica se ritiene, per esempio, che il valore indicato sia ridondante, improprio o sbagliato. In particolare,
sistemi batch di sintesi vocali che impiegano unità di amplificazione grandi, potrebbero impedire la modifica della prosodia se ritengono che questa modifica possa degradare la qualità dell'output finale.
3.3 Altri elementi
3.3.1 Elemento audio
L'elemento audio permette l'inserimento di file audio preregistrati (si veda l'Appendice A per i formati supportati) e l'inserimento di altri formati audio insieme all'output vocale di sintesi. L'elemento audio può essere vuoto. Se l'elemento audio non è un'elemento vuoto allora il suo contenuto deve essere testo marcato che sarà letto se il documento sonoro non è disponibile. Il contenuto alternativo può includere testo, elementi di marcatura, elementi desc e altri elementi audio. Il contenuto alternativo può poi essere usato per la produzione di documenti non sonori e per motivi di accessibilità (si veda l'elemento desc).
L'attributo necessario è src, che è l'URI di un documento con un certo tipo MIME.
&lt;!-- Elemento vuoti --&gt;
Please tell your name after the sound.  &lt;audio src="beep.wav"/&gt;
&lt;!-- Elemento contenitore con testo alternativo --&gt;
&lt;audio src="prompt.au"&gt;Where to you want to fly from?&lt;/audio&gt;
&lt;emphasis&gt;Welcome&lt;/emphasis&gt; to Voice Portal.
Un elemento audio viene riprodotto con successo:
se la sorgente audio a cui si fa riferimento viene riprodotta, o
se il sintetizzatore vocale non riesce ad eseguire #1 ma il contenuto alternativo viene riprodotto con successo, o
se il sintetizzatore riesce a capire che vogliamo un risultato di solo testo e il contenuto alternativo è riprodotto con successo.
La decisione delle condizioni di produzione del contenuto alternativo è lasciata al sintetizzatore. Se l'elemento audio non viene riprodotto con successo, il sintetizzatore vocale dovrebbe continuare ad analizzare il documento, notificando all'ambiente di esecuzione il problema.
Il sintetizzatore può rilevare, dopo aver iniziato la riproduzione della sorgente audio, che il file non può essere riprodotto interamente. Per esempio, per problemi di codifica, distrubi sulla rete ecc. Il sintetizzatore può ritenere questo un successo o un insuccesso, ma deve documentare il suo comportamento.
L'elemento audio può contenere solo testo da sintetizzare e i seguenti elementi: audio, break, desc, emphasis, mark, p, phoneme, prosody, say-as, sub, s, voice.
3.3.2 Elemento mark
L'elemento mark è un elemento vuoto che crea un marcatore nella sequenza testo/tag. Ha solo un attributo necessario, name, che appartiene al tipo xsd:token [SCHEMA2 §3.3.2].
L'elemento mark può essere usato per far riferimento ad una specifica locazione nella sequenza testo/tag, e può essere usato anche per inserire un marcatore all'interno di un flusso in uscita per notifiche asincrone. Quando analizza un elemento mark, il sintetizzatore vocale deve compiere una o ciascuna di queste operazioni:
passare all'ambiente di esecuzione il valore dell'attributo name ed allegare informazioni che permettano alla piattaforma di recuperare la posizione corrispondente nel flusso in uscita.
quando il risultato audio di un documento SSML raggiunge l'elemento mark, solleva un evento che includa l'attributo name dell'elemento. La gestione dell'evento è lasciata all'ambiente di esecuzione.
L'elemento mark non influenza il processo di sintesi vocale.
Go from &lt;mark name="qui"/&gt; here, to &lt;mark name="l&igrave;"/&gt; there&igrave;!
3.3.3 Elemento desc
L'elemento desc può apparire soltanto all'interno dell'elemento audio. Quando la sorgente a cui fa riferimento audio non è testo parlato, ad esempio rumori di fondo o suoni vari, dovrebbe contenere un elemento desc il cui contenuto testuale sia una descrizione della sorgente audio (ad esempio, "porta che sbatte"). Se il sintetizzatore vocale produce un output di solo testo, il contenuto del/degli elemento/i desc sostituisce gli altri contenuti alternativi di audio.
L'attributo opzionale xml:lang può essere usato per indicare che il contenuto dell'elemento è in un'altra lingua rispetto a quella del testo che circonda l'elemento. Diversamente da tutte le altre situazioni nelle quali usiamo xml:lang nel documento, la presenza o l'assenza di questo attributo non ha effetti sull'output nel caso semplice di output vocale (invece che testuale).
&lt;!-- Uso normale di &lt;desc&gt; --&gt;
using &lt;voice&gt;.  In this case, the xml:lang attribute on &lt;desc&gt; can be used
&lt;voice xml:lang="de-DE"&gt;
L'elemento desc può contenere solo testo descrittivo.
Cascading Style Sheets, level 2: CSS2 Specification, B. Bos, et al., Editors. World Wide Web Consortium, 12 May 1998. Questa versione della CSS2 Recommendation è http://www.w3.org/TR/1998/REC-CSS2-19980512/. L'ultima versione di CSS2 è disponibile su http://www.w3.org/TR/REC-CSS2/.
Handbook of the International Phonetic Association, International Phonetic Association, Editors. Cambridge University Press, July 1999. Informazioni sull'Handbook sono disponibili su http://www.arts.gla.ac.uk/ipa/handbook.html.
MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, N. Borenstein and N. Freed, Editors. IETF, September 1993. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc1521.txt.
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies., N. Freed and N. Borenstein, Editors. IETF, November 1996. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc2045.txt.
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, N. Freed and N. Borenstein, Editors. IETF, November 1996. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc2046.txt.
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Editor. IETF, March 1997. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc2119.txt.
Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee et al., Editors. IETF, August 1998. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc2396.txt.
Tags for the Identification of Languages, H. Alvestrand, Editor. IETF, January 2001. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc3066.txt.
XML Schema Part 1: Structures, H. S. Thompson, et al., Editors. World Wide Web Consortium, 2 May 2001. Questa versione dell'XML Schema Part 1 Recommendation si trova su http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. L'ultima versione di XML Schema 1 è disponibile su http://www.w3.org/TR/xmlschema-1/.
XML Schema Part 2: Datatypes, P.V. Biron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001. Questa versione dell'XML Schema Part 2 Recommendation si trova su http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. L'ultima versione dell'XML Schema 2 è disponibile su http://www.w3.org/TR/xmlschema-2/.
MIME Media types, IANA. Questa lista di tipi di media registrati dallo IANA, continuamente aggiornata, è disponibile su http://www.iana.org/assignments/media-types/index.html.
Extensible Markup Language (XML) 1.0 (Second Edition), T. Bray et al., Editors. World Wide Web Consortium, 6 October 2000. Questa versione dell'XML 1.0 Recommendation si trova su http://www.w3.org/TR/2000/REC-xml-20001006. L'ultima versione di XML 1.0 è disponibile su http://www.w3.org/TR/REC-xml.
XML Base, J. Marsh, Editor. World Wide Web Consortium, 27 June 2001. Questa versione dell'XML Base Recommendation si trova su http://www.w3.org/TR/2001/REC-xmlbase-20010627/. L'ultima versione di XML Base è disponibile su http://www.w3.org/TR/xmlbase/.
Namespaces in XML, T. Bray et al., Editors. World Wide Web Consortium, 14 January 1999. Questa versione dell'XML Namespaces Recommendation si trova su http://www.w3.org/TR/1999/REC-xml-names-19990114/. L'ultima versione di XML Namespaces è disponibile su http://www.w3.org/TR/REC-xml-names/.
4.2 Riferimenti informativi
Dublin Core Metadata Initiative. Si veda http://dublincore.org/
HTML 4.01 Specification, D. Raggett et al., Editors. World Wide Web Consortium, 24 December 1999. Questa versione dell'HTML 4 Recommendation si trova http://www.w3.org/TR/1999/REC-html401-19991224/. L'ultima versione di HTML 4 è disponibile su http://www.w3.org/TR/html4/.
International Phonetic Association. Si veda http://www.arts.gla.ac.uk/ipa/ipa.html per il sito web dell'organizzazione.
The International Phonetic Alphabet, J. Esling. Questa tabella dei caratteri IPA in Unicode è disponibile su http://web.uvic.ca/ling/resources/ipa/charts/unicode_ipa-chart.htm.
The International Phonetic Alphabet in Unicode, J. Wells. Questa tabella di valori Unicode per caratteri IPA è disponibile su http://www.phon.ucl.ac.uk/home/wells/ipa-unicode.htm.
JEIDA-62-2000 Phoneme Alphabet. JEITA. Una sintesi di questo documento (in giapponese) è disponibile su http://it.jeita.or.jp/document/publica/standard/summary/JEIDA-62-2000.pdf.
Japan Electronics and Information Technology Industries Association. Si veda http://www.jeita.or.jp/.
JSpeech Markup Language, A. Hunt, Editor. World Wide Web Consortium, 5 June 2000. Copyright ©2000 Sun Microsystems, Inc. Questa versione del documento su JSML si trova su http://www.w3.org/TR/2000/NOTE-jsml-20000605/. L'ultima nota del W3C sul JSML è disponibile su http://www.w3.org/TR/jsml/.
Pronunciation Lexicon Markup Requirements, F. Scahill, Editor. World Wide Web Consortium, 12 March 2001. Questo documento è in corso di sviluppo. Questa versione di Lexicon Requirements si trova su http://www.w3.org/TR/2001/WD-lexicon-reqs-20010312/. L'ultima versione di Lexicon Requirements è disponibile su http://www.w3.org/TR/lexicon-reqs/.
RDF Primer, F. Manola and E. Miller, Editors. World Wide Web Consortium, 10 February 2004. Questa versione del RDF Primer Recommendation si trova su http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. L'ultima versione del RDF Primer è disponibile su http://www.w3.org/TR/rdf-primer/.
RDF/XML Syntax Specification, D. Beckett, Editor. World Wide Web Consortium, 10 February 2004. Questa versione del RDF/XML Syntax Recommendation si trova su http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. L'ultima versione del RDF XML Syntax è disponibile su http://www.w3.org/TR/rdf-syntax-grammar/.
RDF Vocabulary Description Language 1.0: RDF Schema, D. Brickley and R. Guha, Editors. World Wide Web Consortium, 10 February 2004. Questa versione del RDF Schema Recommendation si trova su http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. L'ultima versione del RDF Schema è disponibile su http://www.w3.org/TR/rdf-schema/.
Speech Synthesis Markup Requirements for Voice Markup Languages, A. Hunt, Editor. World Wide Web Consortium, 23 December 1999. Questo documento è in corso di sviluppo. Questa versione dei Synthesis Requirements si trova su http://www.w3.org/TR/1999/WD-voice-tts-reqs-19991223/. L'ultima versione dei Synthesis Requirements è disponibile su http://www.w3.org/TR/voice-tts-reqs/.
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, et al., Editors. IETF, June 1999. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc2616.txt.
Format for Literal IPv6 Addresses in URL's, R. Hinden, et al., Editors. IETF, December 1999. Questo RFC è disponibile su http://www.ietf.org/rfc/rfc2732.txt.
"SABLE: A Standard for TTS Markup", Richard Sproat, et al. Proceedings of the International Conference on Spoken Language Processing, R. Mannell and J. Robert-Ribes, Editors. Causal Productions Pty Ltd (Adelaide), 1998. Vol. 5, pp. 1719-1722. Le relazioni delle conferenze sono disponibili dall'editore su http://www.causalproductions.com/.
Synchronized Multimedia Integration Language (SMIL 2.0), J. Ayars, et al., Editors. World Wide Web Consortium, 7 August 2001. Questa versione del SMIL 2 Recommendation si trova su http://www.w3.org/TR/2001/REC-smil20-20010807/. L'ultima versione del SMIL2 è disponibile su http://www.w3.org/TR/smil20/.
The Unicode Standard. The Unicode Consortium. Informazioni sullo Standard Unicode e sulle sue versioni possono essere trovate su http://www.unicode.org/standard/standard.html.
Voice Extensible Markup Language (VoiceXML) Version 2.0, S. McGlashan, et al., Editors. World Wide Web Consortium, 16 March 2004. Questa versione della VoiceXML 2.0 Recommendation si trova su http://www.w3.org/TR/2004/REC-voicexml20-20040316/. L'ultima versione del VoiceXML 2 è disponibile su http://www.w3.org/TR/voicexml20/.
Questo documento è stato scritto con la partecipazione dei seguenti membri del W3C Voice Browser Working Group (elencati in ordine alfabetico):
Jerry Carter, Consulente Indipendente
Appendice A: Formati dei file audio
Questo appendice è normativo.
L'SSML richiede che la piattaforma supporti la riproduzione dei formati audio specificati qui sotto.
Formati audio richiesti
Raw (headerless) 8kHz 8-bit mono mu-law (PCM) canale singolo. (G.711)
audio/basic (da [RFC1521])
Raw (headerless) 8kHz 8 bit mono A-law (PCM) canale singolo. (G.711)
WAV (RIFF header) 8kHz 8-bit mono mu-law (PCM) canale singolo.
WAV (RIFF header) 8kHz 8-bit mono A-law (PCM) canale singolo.
Il tipo MIME 'audio/basic' è comunemente conosciuto come formato 'au' come il formato headerless 8-bit 8Khz mu-law. Se viene specificato questo tipo MIME per la riproduzione, deve essere usato il formato mu-law. Per la riproduzione di tipi MIME 'audio/basic', i sintetizzatori devono supportare il formato mu-law e possono supportare il formato 'au'.
Appendice B: Internazionalizzazione
L'SSML è un'applicazione di XML 1.0 [XML] e supporta [UNICODE] che definisce un set di caratteri universale.
L'SSML fornisce un meccanismo per il controllo della lingua della voce attraverso l'uso dell'attributo xml:lang. I cambi di lingua possono avvenire anche per ogni parola, sebbene eccessivi cambi di lingua possano diminuire la qualità del risultato. L'SSML permette anche un controllo più fine sulla pronuncia attraverso gli elementi lexicon e phoneme, caratteristiche che possono aiutare a migliorare la bassa qualità dei lessici di default anche per lingue che hanno ad oggi un supporto commerciale minimo.
Appendice C: Tipi MIME ed Estensioni di File
Il W3C Voice Browser Working Group si è rivolto all'IETF per registrare un tipo MIME per lo Speech Synthesis Markup Language. Viene proposto l'uso di "application/ssml+xml".
Il W3C Voice Browser Working Group ha adottato la convenzione di usare l'estensione ".ssml" per i documenti Speech Synthesis Markup Language nei quali l'elemento radice è speak.
Appendice D: Schema per lo Speech Synthesis Markup Language
Lo schema di sintesi si trova su http://www.w3.org/TR/speech-synthesis/synthesis.xsd.
Note: lo schema di sintesi include una schema senza namespace, che si trova su http://www.w3.org/TR/speech-synthesis/synthesis-core.xsd, che può essere usato come base per scrivere frammenti di Speech Synthesis Markup Language (Sez. 2.2.1) all'interno di schemi con namespace diversi.
Appendice E: DTD per lo Speech Synthesis Markup Language
Il DTD dell'SSML si trova su http://www.w3.org/TR/speech-synthesis/synthesis.dtd.
A causa dei limiti dei DTD, il DTD dell'SSML non esprime correttamente il fatto che l'elemento metadata possa contenere elementi di altri namespace XML.
Appendice F: Esempi di SSML
Questo appendice è informativo.
Qui sotto trovate un esempio di lettura delle intestazioni di alcuni messaggi email. Gli elementi p e s vengono usati per marcare la struttura del testo. L'elemento break viene posizionato prima dell'ora ed ha l'effetto di rimarcare l'ora come informazione importante alla quale l'ascoltatore debba prestare attenzione.
L'elemento prosody viene usato per rallentare la velocità di lettura dell'oggetto delle email in modo che l'utente abbia tempo a sufficienza per ascoltare e segnarsi qualcosa.
Il seguente esempio combina file audio e varie voci di lettura per dare informazioni su una collezione di dischi.
Succede spesso che qualcuno voglia includere delle frasi in lingua straniera (come il titolo di un film) in una applicazione, senza aver bisogno di cambiare lingua (magari attraverso l'elemento voice). Un modo semplice di realizzare questa cosa viene esposto di seguito. In questo esempio il sintetizzatore vocale leggerà il titolo del film usando le regole di pronuncia della lingua scelta ("en-US" in questo caso), cercando di parlare (e pronunciare) come farebbe qualcuno che non conoscesse quella lingua straniera.
Con alcuni accorgimenti possiamo decisamente migliorare la qualità audio sia creando una pronuncia personalizzata in un lessico esterno (si veda la Sezione 3.1.4) sia con l'elemento phoneme come mostrato nel prossimo esempio.
È importante notare che il supporto all'alfabeto IPA è una caratteristica opzionale e che i fonemi per una lingua esterna possono essere sintetizzati con una certa approssimazione (si veda la Sezione 3.1.4 per maggiori dettagli). Il seguente esempio (n.d.t, che non verrà tradotto) usa solo fonemi comuni in inglese americano.
Esempio di integrazione con SMIL
Il linguaggio SMIL [SMIL] è un linguaggio di controllo multimediale basato su XML. È progettato specificamente per la descrizione di applicazioni multimediali dinamiche per includono voci sintetizzate.
Il file 'greetings.ssml' contiene:
SMIL Esempio 1: appare il logo del W3C, e poi, dopo un secondo, viene sintetizzata la sequenza vocale. Il file 'greetings.smil' contine:
SMIL Esempio 2: appare il logo del W3C, poi un click sull'immagine causa la sua sparizione e l'inizio della sequenza vocale. Il file 'greetings.smil' contiene:
&lt;img id="logo" src="http://w3clogo.gif" region="whole" begin="0s" end="logo.activateEvent"/&gt;
Esempio di integrazione con VoiceXML
Riportiamo un esempio di SSML nel VoiceXML (si veda la Sezione 2.3.3) per applicazioni di browser vocale. È importante notare che il namespace del VoiceXML include gli attributi e gli elementi del namespace dell'SSML. Si veda l'Appendice O del [VXML] per maggiori dettagli.
Appendice G: Riassunto delle modifiche fino alla versione Candidate Recommendation
Riportiamo una lista delle modifiche a questa specifica fino alla Candidate Recommendation:
Rimossa la definizione, inutilizzata, di "Errore Fatale" dalla sezione 1.5. (CR155)
Aggiunti i riferimenti e la descrizione di RDF dalle sezioni 3.1.5, 3.1.6 e 4. (CR166)
Rimossa "aggiunta di dichiarazioni XML" dalla sezione 2.2.1. (CR170)
Revisionato il punto 4 del paragrafo 1.2, per rimuovere le implicazioni del fatto che tutti i sintetizzatori usano i fonemi come unità acustica di base. (CR183)
Puntualizzato, nella sezione 3.2.4, il fatto che l'uso dell'elemento <prosody> senza attributi è sia errore. (CR184)
Puntualizzato, nella sezione 3.2.1, il fatto che l'uso dell'elemento <voice> senza attributi è sia un errore. (CR185)
Cambiato audio/wav in audio/x-wav nell'Appendice A perchè il primo tipo non è ancora registrato dallo IANA. (CR186)
Aggiornati l'indice e i titoli delle sezioni. (CR190)
Aggiornata la bibliografia informativa sul VoiceXML 2.0 per puntare alla Recommendation.
Aggiunto "(SSML)" al titolo.
Collegate le occorrenze di "error" alla definizione nella sezione 1.5.
Rimosso il riferimento ad HTML dalla sezione 3.1.5. (CR191)
Vari aggiustamenti editoriali

References: §19
 §3
 §2
 §2
 §2
 §2
 §2
 §19
 §2
 §7
 §5
 §3
 §3
 §3